agent4-io

Showing 25 of 50 from the live probe.

• 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**, no need to list them — but note that passing `tools` at all replaces that default list, so include them yourself if you pass any); knowledge_bases = attached knowledge base names (once attached

• 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_tools` / `remove_tools` (and add_/remove_skills, add_/remove_knowledge_bases): incremental, idempotent, leaves the rest untouched. After the call, **read the response** to verify the final list —

• 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}/s/<token>`) and the website embed URL (`{public_base}/embed/<token>`). For a website widget, paste one line before </body>: `<script src="{public_base}/embed.js" data-token="<token>"></script

• 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 delete the old one. That would mint a new token, so the link already embedded in the client's site would stop working — the visible name and the address are not the same thing. - `theme_co

• 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 (required). - `icon_source_url`: public URL of one master image (PNG/JPG/WebP ≥192×192, ideally a square logo). The server derives the full set: browser-tab favicon(48) + install icons 192/512 +

• 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 CNAME at their DNS provider pointing to the `cname_target` in the response (`endpoint.agent4.io`). Key points: - **Subdomains only** (`chat.client.com`). An apex domain (`client.com`) cannot c

• 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** ("user gives a phone number → must call save_contact"), the trigger must be written into description, otherwise models often answer directly without loading the skill and the rule never take

• 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 at chat time on any agent the skill is attached to — no need to also add them to the agent's tools.

• 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 routing, capturing only the model's tool-call decision: **tool side effects are NOT executed**, no session is stored. Tokens count toward the tenant quota (messages≤5, samples≤5, at most 25 calls

• 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, or missed when it should. One line, in the words a visitor would use, naming the subject **and the boundary**: "Country-by-country medical device registration requirements — not company or pr

• 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 `/knowledge-bases/{name}/documents/upload`. **To ingest a whole folder, zip it and send that one endpoint** — subdirectories are walked, md/txt/pdf/html/docx are ingested one by one, and document n

• 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 knowledge base".

• 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 per category" are not answered badly — they are structurally unanswerable. This builds a small per-KB table from whatever structured header the documents share, which the agent can then query

• 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 with `word_count` 0 — those are not zeros, they are missing values recorded as 0, and they silently poison every average, minimum and range filter built on them. Report the warnings to the u