MCP for AI Agents
Connect AI agents to Knova through the Model Context Protocol (MCP).
What is MCP?
The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data. An MCP server describes what it can do as a set of tools. An AI agent connects, sees those tools, and calls them to answer questions or take actions on a person's behalf.
Without MCP, every AI application needs its own custom integration for every system. With MCP, a system exposes its tools once, and any MCP-capable agent can use them.
Knova and MCP
Knova provides an MCP server, so AI agents can work with your Knova deployment in plain language. Agents use the same tools as Knova Agent, the assistant built into the admin UI.
Why agents reason well on Knova
An agent isn't looking at a list of balances. Each Digital Twin is linked to its contracts, workflows, asset rules, location and encumbrances, so the agent can follow those links to answer the question in context.
What agents can do with Knova
- Ask. Query balances, assets under management, asset codes and automations.
- Draft. Describe a rule in plain language and have the agent draft the automation for a person to review.
- Manage. Find, enable, disable and run existing automations, and check how their runs went.
- Monitor. Watch balances and automation runs, and flag exceptions to the right team.
Guardrails
Agents connect with their own credential and work within your permissions and policies. New automations start disabled until they are enabled, and every request is recorded. See Permissions and policy and Audit.
Connect
Knova's MCP server uses the Streamable HTTP transport at a single URL:
https://<your-knova-host>/v1/mcpPoint your MCP client at that URL and authenticate with [credential]. The client handles the rest: it initializes a session, receives a session ID, and includes it on every later request.
| Method | Purpose |
|---|---|
POST /v1/mcp | Send messages to the server. The first request initializes the session. |
GET /v1/mcp | Open or resume the server-to-client stream. |
DELETE /v1/mcp | Close the session. |
These endpoints are meant for MCP clients, not for direct calls. See the MCP transport reference for the full operations.
Most MCP clients accept a server URL and an authentication header in their settings. The exact format depends on the client, so check its documentation.
Example prompts
- "Is this bond eligible collateral under the repo contract?"
- "What happens to my collateral if the margin ratio drops below 1.1?"
- "When the margin ratio drops below 1.1 on the bond repo contract, post enough collateral to restore the floor."
The last prompt is the MCP version of Path B in Automations: describe the rule in plain language, and Knova creates the template. The other two paths are JSON through the API and the UI.
Tools
Your agent discovers the available tools when it connects, and the list below covers what Knova exposes today. Read tools return information. Write tools change something and run under the connecting credential's permissions.
Automations
| Tool | Type | What it does |
|---|---|---|
automations_get_capabilities | Read | Lists the triggers, conditions and actions available, with their schemas. Agents call it first, before creating or changing an automation. |
automations_list_automations | Read | Lists automations, with filters for name, status, frequency and type, and sorting. |
automations_list_by_name | Read | Finds automations by name. Agents use it to turn a name into an ID. |
automations_get_automation | Read | Returns one automation's definition. |
automations_list_automation_runs | Read | Lists the runs of an automation. |
automations_set_automation | Write | Creates an automation from a trigger, a condition and an action. New automations start disabled and run once, unless set otherwise. |
automations_update_automation | Write | Changes an automation's definition. Only the fields you send change. |
automations_set_automation_status | Write | Enables or disables an automation. |
automations_run_automation | Write | Runs an active automation now, outside its schedule. Its conditions still apply. |
Balances
| Tool | Type | What it does |
|---|---|---|
balances_get_aum | Read | Returns total assets under management in USD, with a per-asset breakdown. |
balances_list_all_asset_balances | Read | Returns the total balance of each asset, with filters. |
balances_list_all_user_balances | Read | Returns balances by account, with filters. |
Assets
| Tool | Type | What it does |
|---|---|---|
asset_codes_list | Read | Searches the supported asset codes. Other tools that take an asset code need one of these exact codes. |
Working with automations
An agent usually follows this order: call automations_get_capabilities, create the automation with automations_set_automation, then enable it once it has been reviewed. Use automations_list_by_name to find an existing automation before reading, changing or running it.
Permissions and policy
An agent can only use the tools its user is allowed to use.
- Tool permissions. Knova can check whether a user may call a specific MCP tool. The check returns whether access is allowed, the permission required, and the reason for a denial.
- Policy rules. Policy rules decide whether a request is allowed, and the outcome is recorded as a policy decision.
- Human approval. Where it's configured, a request waits for a person to approve it.
For how credentials and signatures work across Knova, see the Security Overview.
Audit
Policy decisions and audit events record which agent and session made a request. Together with the audit trail for every workflow step, you can trace any action back to the request that caused it.
Related
- Digital Twins: the asset model agents work from
- Knova Agent: the assistant built into the admin UI
- Automations: rules you can create by prompt
- Configurable Workflows
- Security Overview
Updated about 2 hours ago