io.agent4/agent4-tenant · v1.4.0 · agents-and-memory
agent4.io is healthy: it completed an MCP handshake in 3092 ms and exposes 50 tools.
Build and run grounded business agents over MCP: agents, knowledge bases, skills, Storylines.
Endpoint: https://api.agent4.io/v1/mcp (streamable-http)
No repository listed · Website · JSON · Add to my inventory
| Users (last 30 days) | 0 |
| Handshake | Healthy |
| Auth needed | None |
| Tool count | 50 |
| Latency | 3092 ms |
| Last checked (UTC) | 2026-10-15T00:15:46.682Z |
| Checked (UTC) | Status | Latency | Error |
|---|---|---|---|
| 2026-10-15T00:15:46.682Z | Healthy | 3092 |
list_agents | List all agents in this tenant (name + published state). |
get_agent | Get one agent's full configuration (soul/task/tools/skills/knowledge_bases/model/params). |
create_agent | Create an agent. `name` is lower-cased on save — it is a key, not a display name. soul = persona/identity; task = duties and boundaries; tools = tool-name whitelist (check list_tools first; the system tools time/geo/weather **and `compute_chart`** are **auto-enabled by default**, n |
update_agent | Update **part** of an agent — fields you don't pass stay as they are. ⚠️ List-field semantics, don't mix them up: `tools=[...]` / `skills=[...]` / `knowledge_bases=[...]` are **full-list replacement** — items you didn't read first get pushed out. To "add one / remove one", use `add_tool |
list_tools | List tool names assignable to agents, with their descriptions (incl. the tenant's connected MCP tools). |
list_mcp_servers | List the MCP servers connected in this tenant's tool library (read-only; secret fields omitted). |
create_share | Create a **share / integration entry point** for an agent — this is how end users actually reach it. **`published=True` only means "visible", not "reachable"**: for end users to talk to the agent you must create a share. The response carries a directly openable chat link (`{public_base} |
list_shares | List an agent's shares (token / label / disabled / chat link / embed URL / appearance config). When the top-level `pretty_url` is non-empty it is the preferred link to give humans (see create_share). |
configure_share | Configure this share — its name and its **appearance** — fields you don't pass stay as they are (server-side partial merge). - `label`: the name at the top of the chat page, and the browser tab's title. **Renaming a share is this call**; you never need to create a replacement and dele |
set_pwa_branding | Configure a specific **agent's** PWA branding and install experience (applies to that agent's `/s/` standalone chat pages — what gets installed to the home screen is one agent's entry page, so each agent is its own app). - `agent`: the agent name whose install branding to configure (req |
set_custom_domain | Bind the client's own domain to this tenant's chat pages: `https://chat.client.com/` serves the tenant's branded page (or a specific agent's chat), the address bar keeps the client's domain, and the TLS certificate is issued automatically. **Have the client configure DNS first**: add a |
list_skills | List this tenant's skills. |
get_skill | Get one skill's full content (including the complete instructions text). |
create_skill | Create a skill. description = "when to use" (goes into the system prompt, keep it short); instructions = the detailed guide (fetched on demand via load_skill). The paradigm (important): instructions are visible only AFTER the model calls load_skill — if calling some tool is **mandatory* |
update_skill | Update part of a skill — fields you don't pass stay as they are (server-side PATCH merge, no GET+PUT round-trip). ⚠️ `tools=[...]` is **full-list replacement**; to add/remove one use `add_tools`/`remove_tools` (incremental, idempotent). Tools bound to a skill take effect automatically a |
test_skill_trigger | Reality-check whether your prompts actually trigger tool calls (dry-run) — run this after writing/changing a skill instead of counting corpses in production. Replays your messages N times against the **production** system-prompt assembly, tool schemas and this tenant's actual model rout |
list_knowledge_bases | List this tenant's knowledge bases (with doc/chunk counts and relevance cutoff). |
get_knowledge_base | Get one knowledge base's configuration (including the full instructions text shown to the model). |
create_knowledge_base | Create a knowledge base. **Write `description` — it is what routes questions to this base.** Before each answer the platform reads every attached base's `description` and decides which ones this question needs; a base whose description is vague or blank gets searched when it should not, |
update_knowledge_base | Update part of a knowledge base — fields you don't pass stay as they are (server-side PATCH merge). |
add_knowledge_text | Add a **text** document to a knowledge base (chunking + embedding happen synchronously; returns the real chunk count). For **local files** (pdf/docx…) see `add_knowledge_file`. |
add_knowledge_file | Add a local file's content to a knowledge base (txt/md/html/pdf/docx). **This MCP runs on the platform server and cannot read paths on YOUR machine.** For text files, read the content yourself and call `add_knowledge_text`; for binaries (pdf/docx), upload via the console, or curl `/know |
search_knowledge_base | Search this knowledge base; returns matching chunks with distances. Uses **exactly the same retrieval path as real conversations** — use it to validate the cutoff and chunking: an empty result means this question will be judged "not covered" and the agent will answer "not in the knowled |
build_knowledge_index | Build (or rebuild) the structured index for a knowledge base — the second leg beside vector search. Vector search answers "what does this passage say". It **cannot count, filter numerically or aggregate**, so "how many documents", "which ones are between 1000 and 2000 words", "how many |
get_knowledge_index | Show the structured index profile: per column coverage, type, numeric range, top values, warnings. **The warnings are the point.** On a real 4,500-document catalogue this surfaced three data problems nobody knew about: 1,058 documents with `page_count` 0, 505 with `reading_level` 0, 493 |
patch_knowledge_index | Change the structured index schema from one sentence of plain language. Example requests: "also track the author so users can find other books by them", "I want to filter by illustrator", "drop the cover link". The model may only emit add/modify/remove/refused — it cannot rewrite the ta |
improve_prompt | Rewrite a field's text to work better as an AI system prompt; returns the improved text. field ∈ persona | task | greeting | storyline_task | storyline_opening | storyline_ai_trigger | storyline_ai_criteria | skill_description | skill_instructions | kb_description | kb_i |
diagnose_prompt | Read a field and return a list of **specific** improvement suggestions (string array). field: same values as improve_prompt. current = the text to diagnose (required — an empty text has nothing to diagnose). Typical flow: diagnose_prompt first, pick the suggestions you want, then fold t |
test_planner_trigger | Dry-run the Dynamic Planner's escalation judge: would these messages be offered a step-by-step plan? Use it after editing the agent's `task`, since the task text is the **business-domain gate** — a vague task lets out-of-domain requests through, a narrow one turns real customers away. |
preview_plan | Generate a plan for a goal and return it for review **without persisting anything** — no temporary storyline, no enrollment, no user affected. Use it to inspect plan quality before trusting the feature in production, or to see how the agent's `task` constrains the steps. Returns {plan, |
usage_stats | Usage statistics. group ∈ total | agent | user | space | day | model. Metadata only — token counts and event counts, never any conversation content. Use group="user" to see who uses the most, group="agent" for the busiest agent. |
tenant_info | This tenant's basic info and quota (plus custom-domain binding status, if any). |
search_agent4_docs | Search agent4.io's own product docs — concepts (what a thing *is*) and cookbook recipes (which tool to *call*). Use when you're unsure how an agent4.io feature works, what a term means, or how to build something on the platform. Returns top passages with title, layer ("concept"|"ops"), url a |
list_end_users | List this tenant's **end users** (the people chatting with your agents) — roster only, never any conversation content. Each user carries: display name, login method (email / oauth:* / proxy), email (if any), space/session/document counts, last-24h token usage, and a `console_url` (click |
get_end_user | Get one end user's detail: basic profile (name, contact email/phone, city, timezone) + their spaces. Never any conversation content. Carries a `console_url` to the user's detail page. |
list_user_sessions | List one end user's **sessions** — metadata only: agent, title (AI summary), message count, tokens, timestamps. **Message bodies are not returned.** Transcripts are rendered in the console: each session carries a `console_url` that **deep-links straight to that conversation, auto-opened |
list_page_contexts | List all page playbooks of this tenant (with match rules, greeting mode, position). |
upsert_page_context | Create or fully replace a page playbook. `context` is the page background the **server** injects for the agent — write "who lands on this page, what they are deciding, what they usually worry about"; do NOT write facts like prices or quotas (those belong in a knowledge base, which also |
resolve_page_context | Given a URL (or key), show which playbook it resolves to — always verify after writing a match rule. Globs make it easy to write rules that "look right but never match" (one `*` short, one path level too many) — and in production the only symptom is visitors silently getting the default |
page_context_stats | Open counts and suggested-question click counts per playbook — find copy nobody clicks. |
list_storylines | List this tenant's storylines (optionally filtered by agent). Includes state, version, default flag. |
get_storyline | Get one storyline's full definition (whole graph + profile_schema + top-level fields). |
create_storyline | Create a storyline draft. After creating, self-check with validate_storyline, then publish_storyline. user_visibility — what the end user sees of their own run: "invisible" (default, no UI), "named" (a banner with the storyline name only), "trail" (banner + read-only view where unta |
update_storyline | Update **part** of a storyline draft — fields you don't pass stay as they are (GET-then-merge on top of a full PUT underneath). concurrency: "user" = progress belongs to the person (shared across sessions); "session" = progress belongs to the case (one run per session). Changes affect o |
validate_storyline | Validate the storyline graph (entry / dead ends / unreachable / dangling / cross-line targets / rule dimensions). Returns {ok, errors}. Must pass before publishing. |
publish_storyline | Publish a storyline: validates first (blocking errors → 422), then freezes an immutable version and marks it published. |
unpublish_storyline | Unpublish (archive): no more auto-enrolment; in-flight users silently degrade to the plain agent on their next turn (progress kept — re-publishing resumes it). |
clone_storyline | Clone a storyline into a new draft (new key, unpublished, doesn't claim default, no chain pointer) for tweaking. |
export_storyline | Export a portable storyline JSON (schema_version + definition; no tenant/version/id) for backup, migration or re-import. |
import_storyline | Import an exported storyline JSON as a draft. **Artifacts like "generate a storyline from a novel / source material" land here.** payload = the structure returned by export_storyline (schema_version + graph + profile_schema + top-level fields). Version-aware: payloads newer than the sys |