Pathors

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 a memory entry

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.

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 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 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. 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 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, 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. 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 all memories for a project

List the organizations the current user belongs to. An organization is the tenant/billing boundary that OWNS projects, and a project can never be moved between organizations. Call this before create_project and pass the chosen organizationId — omitting it creates the project in the entry flagged "isDefault" (usually the user's personal workspace).

List the phone numbers owned by an organization. Phone numbers are ORGANIZATION assets (not project assets): use list_organizations to find the organizationId, and the caller must be that organization's owner or manager. Each entry shows the business-facing fields — E.164 number, optional PBX extension (the same representative number may appear once per extension), provider, status, label/displayName, and which project answers inbound calls (inboundProjectId). Use get_phone_number for override settings. Telephony internals (trunks, SIP credentials) are not exposed; adding/removing numbers or changing status is admin-panel-only.

List all projects accessible by the current user. Each project carries the organizationId that owns it — pair with list_organizations to tell whose workspace a project lives in.

List the secret handles available to this project — the credential store for tools that call an authenticated external API. Secrets belong to the project's ORGANIZATION and are shared by every project in it. ALWAYS call this before create_tool / update_tool whenever the tool needs an API key, bearer token, or any other credential: put the reference `{{secrets.HANDLE}}` in the metadata (e.g. headers.Authorization = "Bearer {{secrets.CRM_TOKEN}}") instead of a literal value — the reference is expanded in memory at tool execution time, so rotating the credential needs no tool change. NEVER write a literal credential into tool metadata: it would be stored in plaintext. Secret VALUES are write-only and are never returned by any tool — this lists handles only. You CANNOT create, change or delete a secret: if the handle a tool needs is missing, tell the user to add it themselves in Organization Settings → Secrets, then reference it by name.

List session histories for a project with pagination and filters. Returns lightweight summaries (no events). Use get_session for full detail. Filters: - page / pageSize: pagination (default 1 / 20) - startDate / endDate: YYYY-MM-DD format - provider: filter by integration type - search: search by session ID - markedOnly: only marked sessions - hasComments: only sessions with comments

List all test cases for a project. Returns each test case with its configuration and acceptance criteria.

List all test suites for a project. Returns each suite with its id, name, timestamps, and the IDs of connected test cases.

List available tool types that can be created, each with a one-line summary of what it does and when to use it

List all tools configured for a project