Pathors

Create a test case: one simulated-customer conversation scenario used to evaluate the agent. How a test case works: - systemPrompt is the persona/goal of the SIMULATED CUSTOMER the runner role-plays against your agent — NOT the agent's own prompt. - acceptanceCriteria are plain-language pass/fail checks an LLM judge scores the resulting conversation against. - variables ({{key}}) are substituted into the systemPrompt at run time. - mockConfig controls whether the run touches real integrations (see below). Typical MCP workflow: create_test_suite → create_test_case (once per scenario, passing testSuiteId later via update_test_suite, or attach at suite-create time) → run_test_suite → poll get_test_results. mockConfig default: if you OMIT mockConfig entirely, the case is created LIVE (before-start runs real HTTP; post-session posts the real webhook) to match the in-app default. Pass an explicit mockConfig to mock instead. Interpretation is fail-closed per field: within a config you pass, any before-start/post-session field left absent defaults to mock/capture (safe), so set mode:"live" explicitly on each part you want live.

Create a test suite — the runnable unit that groups test cases for batch execution and scoring. Pass testCaseIds to connect existing cases now, or attach them later via update_test_suite. A case can belong to multiple suites. Full flow: create_test_suite → create_test_case → attach → run_test_suite → get_test_results.

Create a new tool for a project in one shot. name, description, and metadata are applied on creation (the inputSchema is derived from metadata automatically: restful uses the queryParams/pathParams ai_input params, mock uses metadata.params) — no follow-up update_tool call is needed. For demo/prototype agents that should not depend on any live API, prefer type "mock" (canned response) over "restful". Tool names must use only lowercase letters, digits, _ and - (^[a-z0-9_-]{1,64}$). CREDENTIALS: never put a literal API key, bearer token or password in metadata — it would be stored in plaintext. Call list_secrets first and reference the handle as `{{secrets.HANDLE}}` (plural "secrets"), e.g. headers.Authorization = "Bearer {{secrets.CRM_TOKEN}}". References may appear in any metadata string and are expanded in memory at execution time, so a rotated credential needs no tool change. If the needed handle does not exist, ask the user to add it in Organization Settings → Secrets — it cannot be created through these tools.

Delete an edge from the pathway. IMPORTANT: Do not call multiple pathway mutation tools in parallel — they perform read-modify-write and will overwrite each other.

Delete an organization integration account and its credential. EVERY project bound to it loses the binding and the integration tools that account backed (check projectCount in list_org_integration_accounts first, and confirm with the user). To stop only one project from using it, use unbind_integration_account instead. Requires the org owner or manager role.

Delete a node and its connected edges from the pathway. IMPORTANT: Do not call multiple pathway mutation tools in parallel — they perform read-modify-write and will overwrite each other.

Delete a project (owner only)

Delete a session comment. Only the comment's author (the authenticated MCP user) may delete it.

Delete a test case from a project. Removes criteria and disconnects from suites.

Delete a test suite from a project. This does not delete the test cases themselves.

Delete a tool from a project. A restful or mock tool is only removed from this project; the organization keeps it on its API Tools page.

End an interactive conversation and persist it. Triggers the normal end-of-session pipeline (final variable extraction, post-session webhook, evaluation). Idempotent — ending an already-ended conversation succeeds without re-running the pipeline.

Get complete agent data (configuration + pathway) for a project. When you are about to edit prompts: prefer structuring rules as promptModules over growing globalPrompt (see update_agent), and consider suggest_prompt_modules to spot recommended voice-rule modules the agent is missing. voiceProfile.additionalLanguages in the response is the resolved effective multilingual set: for a legacy agent still on the deprecated language-detection flag it expands to all supported languages, even though the stored list is empty. The read-only `variables` field lists every variable the agent touches as { key, sources }: "pre_call" = must be supplied before the call (outbound call-list columns / API dynamicVariables), "ai_in_call" / "ai_post_call" = extracted by the AI during / after the call (a call list may still pre-fill them), "system" = injected by the dialer; empty sources = declared but nothing reads or fills it.

Get one automation rule in full: trigger, scope, conditions and every step exactly as stored. Read this before update_automation — steps and conditions are replaced WHOLE, so an edit starts from this list. Requires the org owner or manager role.

Get one automation run with every step it recorded: the request each step sent (credentials already redacted), the response, per-step error and duration, plus the run's error, attempt count and timings. Use after list_automation_runs to diagnose a failed or skipped run. Requires the org owner or manager role.

Guidance for building and changing voice agents on this platform, one topic at a time. Call this BEFORE you write or edit prompt content, tool configuration, or a test case — the bodies carry the current house rules, and they are not repeated in your system prompt. Topics: - `rule-shape` — How to phrase a rule so the agent actually follows it — preconditions over requests, conditions in the main clause, branching on observable fields, and pairing every prohibition with the normal path. - `tool-authoring` — Writing tool configuration: why parameter descriptions are prompt rather than API docs (never a fallback literal), credentials via secret handles, and empty-value handling. - `simulator-and-criteria` — Test cases and the simulator: the LIVE-by-default safety trap, writing criteria the judge cannot misread, why a failed criterion does not mean the agent is wrong, and how many runs a conclusion needs. - `voice-writing` — Voice-first writing rules for any prompt content the agent will speak: turn length, one question per turn, readback of critical values, ASR tolerance, guardrails. - `agent-architecture` — Structuring an agent: monolithic single node by default, the setup order, prompt-module granularity, and what the agent actually reads at a given turn. Returns the topic body as markdown. Project-independent: no projectId, no side effects.

Inspect an interactive conversation's current state without advancing it. Returns the current pathway node, extracted variables, whether the agent has ended the conversation, and message/turn counts. Right after end_conversation, post-session variable extraction may still be running detached — re-read a few seconds later if extractedVariables looks incomplete. Only works on sessions opened with start_conversation.

Get the "Highlights" digest material for a project: everything needed to write a periodic performance report over the sessions in a time window. Returns bounded, structured facts — you (the calling agent) write the narrative: - window + checkpoint (store checkpoint.until as the next call's "since") - summary stats and a previous-window comparison (volume / evaluation deltas) - evaluation breakdown, aware of the project's evaluation type (pass_fail / enum / number), plus the project's evaluation config so option semantics are interpretable - top unanswered knowledge-base queries (zero-hit searches — candidates to add to the KB) - transcript excerpts sampled per evaluation outcome (for topic discovery, sentiment analysis kept separate from success, and timing-of-failure analysis) The result's reportGuide field is the agreed report format — follow it when writing the report.

Get one outbound campaign with how its contacts ended up. Besides the list_outbound_campaigns fields: breakdown.byDispatchStatus (pending/queued/running/completed/failed — the dialer's view), breakdown.byCallStatus (the raw call-log status per contact, e.g. userNoAnswer, invalidNumber, agentHangup; `none` = never dialed or no call log yet), awaitingRetry (contacts the retry policy will re-dial) with earliestNextAttemptAt, dialingWindow (whether it is inside a window now and when the next one opens, in the campaign timezone), and failureReasons: the non-connected outcomes grouped by their RAW cause, e.g. `invalidNumber · sip 403 No International Permission` → 37. IMPORTANT: the dashboard shows `invalidNumber` for many carrier/permission failures (SIP 403 forbidden / no international permission, 404, 484 address incomplete) — read failureReasons for the real cause before telling the user the numbers are bad. Each group carries sampleContactIds to inspect with list_outbound_campaign_contacts.

Get one phone number with its inbound routing details: the bound project (inboundProjectInfo) and the per-number override config (voice/language/background-audio/thinking-sound override flags, an optional voiceProfile override, and a fallbackPhoneNumber to forward to when no agent answers). Find the phoneNumberId via list_phone_numbers — lookup is by id, so numbers sharing an E.164 across extensions are unambiguous. inboundConfig is null when the number has no overrides (it then fully follows the bound project settings).

Get project details by ID (includes the owning organizationId)

Get one QA profile in full — every check (id, kind, name, enabled, severity, config), the default sampling and the judge model — plus `authoring`: what each check kind measures, its config fields with their ranges and defaults, severities, judge tiers, templates and limits. ALWAYS read this before create_qa_profile, upsert_qa_check or update_qa_profile. Requires the org owner or manager role.

Get one QA run's report: status and progress; meta (time window, projects, sampled vs requested, judge model, credits charged); KPIs (pass rate, p90/max latency, interruption rate, longest dead air after the caller finished speaking — transfers left out — and how many calls had timing data); every check as the report table orders it — failing first by failed calls, then passed, not applicable, undetermined, errored, pending — with fail/decided counts, a display tier for failing checks (occasional ≤10% failed, attention ≤30%, failing above; a critical check one tier up — verdicts are unchanged) and a one-line summary; the 10 slowest replies of the run (call, latency, whether the reply waited on a tool call and which tools, the words); pass/fail per project; agent sentences interrupted 2+ times; silenceByCause (agent-owed silences over the dead-air threshold by cause: stall | lookup | transfer); silenceHistogram (caused silences over that same threshold by length bucket fromMs/toMs and cause — the first bucket starts at the threshold, then 10 s, 20 s, 40 s; shorter gaps are turn-taking and left out); transfers (outcomes connected | failed | abandoned | unknown, wait p50/max; null for runs evaluated before transfer detection); and the settings snapshot (checks, sampling, judge model) the run used, which may differ from the profile today. Rates are fractions 0–1, durations ms. Drill into calls with list_qa_run_calls. Requires the org owner or manager role.

Get full session detail: the complete event timeline, tool calls included. This is the primary tool for debugging agent behaviour. `events` is the whole narrative (serialized messages, decisions, extracted variables, tool calls, ...) in time order. A tool call is a `tool.called` event (or `tool.external_call` for one the voice worker ran itself) whose `data` carries the typed record: `outcome` (ok | http_error | network_error | timeout | threw | delegated), `statusCode`, `durationMs`, `toolName`, `toolCallId`, and its capped input/output, so a failure is read off the event rather than guessed from the output text. Discarded turns are folded by default. When the caller speaks again before the agent replies, that turn is never committed: the next request carries its caller lines along (`message.received` `data.messages` holds the whole turn) and re-runs from the node it started on. This is by design, not a bug — the discarded turn's decisions and tool calls never took effect. Its events are folded into its `turn.aborted` row: `data.reason` (superseded | client_aborted | never_committed), `data.supersededBy` (the committed request that replaced it, when known) and `data.discarded` (`eventCounts` by type, `callerMessages`). Tool results the model still saw, variable extractions (stored without a commit, so they did take effect) and replies the caller heard are not folded. `session.committed` `data.supersedes` lists the turns a commit replaced. Pass `includeDiscardedTurns: true` for the raw, unfolded list. Also included are any human-authored comments left on the session (the `comments` field, not just a count). Treat those comments as reviewer feedback: read them and use the agent tools (update_agent, add_prompt_module, ...) to act on the requested changes. The project is inferred from the session itself; no projectId needed.

List the human-authored comments left on a session. Use this to read reviewer feedback on a specific session without pulling the full event timeline. Each comment includes its author and text. Consume these as instructions/feedback and act on them with the agent tools (update_agent, add_prompt_module, ...). The project is inferred from the session.

Get session statistics for a project (session counts over time). Useful for observability dashboards.

Get a single test case by ID, including its configuration and acceptance criteria.

Get test results for a test suite. Returns every run (newest included) with, per test case: overall status, the full conversation transcript (messages), each acceptance criterion's pass/fail with the judge's reasoning (criteriaResults), token usage/cost, and the underlying sessionId. Poll this after run_test_suite until status is no longer RUNNING.

Get a single test suite by ID, including its connected test case IDs.

Get a specific tool configuration

Insert pre-split chunks directly into a knowledge base. Each string becomes one chunk (no further splitting). Chunks are attached to a new dataset and embedded synchronously.

Insert a dataset into a knowledge base from raw text. The text is split using the KB chunk settings and embedded synchronously (this call returns once embedding completes).

List an organization's automation runs, newest first — one run per (rule, session, trigger). Use it to check whether a rule fired and why it failed or skipped; open one with get_automation_run for per-step requests and responses. status: pending | running | succeeded | failed | skipped (a condition did not hold, or the loop guard stopped a rule that kept running for the same person — `error` says which) | captured (test-runner dry run, nothing sent). Requires the org owner or manager role.

List an organization's automations — post-call rules that fire on a session event (trigger), filter with conditions, then run steps (integration actions, http calls, transforms) in lanes. Returns each rule with a step summary, run count (live runs only) and last run. Call list_organizations first for the organizationId; requires the org owner or manager role. Use get_automation for a rule's full conditions and steps.

List the built-in prompt module catalog — a curated set of common VOICE agent rules (voice output formatting, one-question-per-turn, ASR tolerance, concise responses, no-echo, natural fillers, role lock, timezone/time format, no fabrication, confirming critical details, recording notice, surname decomposition, off-topic reframing, escalation to a human, de-escalation), grouped as fundamental / recommended / optional. Each is a localized template: copy one into an agent with add_prompt_module (its content is a good starting point) and edit as needed. Built-ins are NOT enabled on any agent until added. Consult this BEFORE authoring prompt-module content from scratch, and prefer a matching preset. Pass `locale` (e.g. "zh-TW") to get each preset's name / description / body in the agent's language; defaults to English. Pass `projectId` to also get `alreadyAdded` per preset (whether the agent already has a module with that name) — handy for spotting gaps. To get just the recommended presets the agent is MISSING, use suggest_prompt_modules instead. Returns [{ id, name, description, content, builtin, group, order, defaultEnabled, alreadyAdded? }]. `defaultEnabled` marks presets the catalog recommends be on (fundamental + recommended groups).

List the chunks of a dataset in a knowledge base

List the datasets in a knowledge base

List the INTEGRATION tools of a project — the platform-owned actions the agent can take mid-conversation (endCall, transferCall, requestTakeover, chatwoot transfer_to_human). These are separate from list_tools, which covers only the custom tools the project itself created; an integration tool has no id, is addressed by toolName, and is configured with update_integration_tool. Each entry reports the effective description (an override, or the built-in default), whether the agent may call it (enabled), whether its owning integration is switched on at all (integrationEnabled), and any per-tool settings — for transferCall that is the destination allowlist. requestTakeover only reaches the agent while the project's Pathors Inbox voice bridge is on, so its integrationEnabled reports that bridge. Read this before touching a tool's description or allowlist, so the edit starts from what is actually configured.

List the knowledge bases for a project, including each one's searchInstruction — the text the agent's knowledge-search tool is described with at call time (null = built-in default). Edit it with update_knowledge_base.

List the organization's connected integration accounts (HubSpot workspace, Slack workspace, …). An integration step MUST name one of these as integrationAccountId, of the same provider and not revoked. Returns metadata only — credentials are never exposed. If the provider you need has no account, tell the user to connect it in Organization Settings → Integrations; you cannot connect one. Requires the org owner or manager role.