Resources & MCP

Resources are tenant-defined datasets — your own entity types with custom fields. They let the AI agent answer with live, per-customer data (order status, subscription, ticket number, etc.) instead of only static knowledge-base content.

Define a resource type#

A resource type has:

• Names — singular and plural labels, translatable per language.
• A slug — a stable identifier.
• Fields — each with a key, a type, whether it's required, and a sort order.
• An identifier hint (optional) — how a customer names one record in their own words, e.g. "a tracking code starting with CMX" or "your booking reference". The AI agent asks for exactly this the moment a question is about this dataset. When it's empty, the agent falls back to the first required field's label.

Supported field types: string, number, boolean, datetime, url, and json.

Records and values#

A resource item is one record of a resource type. Items can be tied to a customer (via an external customer ID) and to an external_id, and they hold typed values for each field.

Attaching to channels#

Resources are attached to channels you choose. The AI agent can only use a resource on a channel where resource access is enabled and that resource is attached. When attached, the agent gains tools to:

• list a customer's records of a resource type,
• look up a specific record — picking whichever of your MCP tools answers the question (e.g. status, item details, or shipping),
• present record shortcuts as tappable chips in the widget.

How customers pick a record#

When a customer chooses a data type (for example Orders) and several of their records match, the agent doesn't print a long list to read through. Instead it shows one tappable chip per record — labelled with the resource name and the record's identifier (e.g. an order number) — and invites the customer to tap the one they want. Tapping a chip pulls that record's details so the agent can answer about it, and the customer can tap another chip to look at a different record.

MCP: connecting your live data#

Rather than importing your data, Chatasist reads it on demand by acting as an MCP client to an MCP server you host.

You register that server once, under Integrations → MCP servers — its URL and any credentials live there, stored encrypted, with its own health status and an on/off switch. See MCP servers for how to add one. A resource then just points at a registered server and names the tool it uses:

• MCP server — pick one of your registered servers from the dropdown.
• Default MCP tool — the tool to call for lookups (leave blank to auto-detect).

Because the server is shared, several resources can point at the same one, and you change a URL or rotate a token in a single place. A resource with no server selected is fine — it is simply static data with no live lookup, and the agent asks for an identifier rather than fetching anything.

At answer time Chatasist calls that server over JSON-RPC (tools/list, tools/call), passing the current customer's identifier. Results are injected into the agent's context as structured data.

Chatasist reads each tool's published input schema (from tools/list) and automatically maps the customer identifier and the record identifier onto the argument names your tool declares. A lookup tool that expects order_id, ticket_id, or ref works without any extra configuration — you only need the overrides below if a tool's arguments can't be inferred.

If your server exposes several per-record tools (for example separate status, item-detail, and shipping tools), the agent picks the one that matches the customer's question — so "where is my order" and "what's in my order" can resolve to different tools for the same record.

If a tool reports a failure (an MCP isError result), the agent tells the customer it couldn't find the record and asks them to double-check the identifier — it never presents the error message back as if it were data.

Authentication and argument mapping#

Authentication headers (for example a bearer token) are set on the MCP server under Integrations → MCP servers, not on the resource — so they are entered and stored once, and encrypted. Every resource pointing at that server uses them.

Argument names are inferred from each tool's published input schema, so a lookup tool that expects order_id, ticket_id, or ref works with no extra configuration. Naming a Default MCP tool on the resource is only needed when a server exposes several tools and you want to fix which one a list/lookup uses.

See it in the inbox

How conversations flow once channels and AI are set up.