Tools are where an agent stops talking and starts working.
This page covers the connective tissue: four tiers of plugins, the built-in tool catalogue, parameter-driven custom plugins, MCP in both directions, the adoption of agents you did not build, and the published surfaces your users and systems actually call.
First, second, third, custom
Each tier has a different cost structure, and choosing the wrong one is how tool bills get out of control
MCP, both ways
Call external MCP servers, and publish your own workflows as MCP servers for others to consume
Adopt what exists
Third-party and in-house agents register into one entry point instead of being rebuilt
APIs without code
An existing API becomes a plugin through parameters, tested online before it is bound
Four plugin tiers, four different commercial relationships
The tier determines who invoices you, who holds the credential, and who is accountable when the call fails at three in the morning. Deciding this per plugin, deliberately, is part of the architecture — not a procurement detail.
Provided by the platform, deployable on your infrastructure
These ship with the platform and can be deployed alongside it, locally. They are usable straight out of the deployment with no additional charge and no external account to open.
- Best for — capabilities that must work in a private or air-gapped estate, and tools where adding a third-party dependency is politically or contractually impossible.
- What you do — enable the tool in deployment settings and, where it touches internal data, give it the same access path you would give a service account.
- Ownership — the platform team maintains the tool; your team owns the configuration, the credentials and the monitoring.
Cost structure
No separate line item. The cost is inside your platform commitment and, where relevant, your own infrastructure footprint.
Watch for: if a capability in this tier later needs a hosted dependency, it stops being deployable locally. Ask before you architect on top of it.
Cloud services the platform integrates officially
These are commercial cloud services with a first-class integration. To use one you open an account with that provider, apply for access keys, and the platform calls it on your behalf.
- Best for — capabilities that only make sense as a hosted service, where buying a second relationship would be wasteful.
- What you do — register the account, hold and rotate the access key pair (AK/SK) in your own secret store, and agree the billing relationship directly with that provider.
- Ownership — the provider owns the service and its SLA; you own the key, the spend and the data that crosses the boundary.
Cost structure
Billed by the cloud service, on that provider's own metering. It does not appear on your platform invoice, which means it will not be governed by your platform cost controls unless you wire it that way.
Watch for: credentials live in your estate, so rotation and revocation need a named owner.
Third-party cloud services with no direct relationship
Also integrated by the platform, but you register and pay with the third party yourself. There is no commercial relationship between you and the platform for these.
- Best for — specialist services where you already have a vendor, or where an existing contract gives you better terms than the platform could.
- What you do — register on the vendor's own platform, apply for the credentials there, and accept the vendor's data handling terms in your own name.
- Ownership — entirely yours, including the security review. The platform provides the connector, not the assurance.
Cost structure
Billed by the third party on their terms, at your negotiated rate. This is often the cheapest route for a company with an existing enterprise agreement.
Watch for: connector behaviour can lag the vendor's own API changes. Pin expectations in a regression test, not in a promise.
Your existing API, packaged as a plugin without writing call code
A custom plugin turns an endpoint you already operate into something an agent can call. It is configuration — name, description, address, method, headers, parameter rules and output mapping — not a development project. For a business analyst with API documentation, this is an afternoon's work rather than a sprint.
- Best for — internal services, legacy endpoints, ERP and CRM APIs, and anything a vendor will not put behind a connector.
- What you do — describe the request and the response, press Test until the mapping is right, then bind the plugin to an agent.
- Ownership — you own the endpoint, its availability, its rate limits and its data classification.
Cost structure
No licence cost for the plugin itself. The cost is engineering time in your own team to make the endpoint stable enough for an agent to depend on.
Integration in numbers
Four different commercial relationships, not one bundle
Your tools exposed to agents, and agents exposed as tools
The endpoint you already run becomes a tool without being rewritten
Callers prove who they are, per request
Four plugin tiers, four different commercial relationships
Conflating these tiers is how organisations end up paying for something they assumed was included, or building something they were entitled to.
Tier 1 — Foundation tools
What every agent needs before anyone writes a plugin: web access, file handling, calculation, code execution in a sandbox, and structured output. Included in the platform because an agent without these is a toy.
Tier 2 — Your internal systems
ERP, CRM, ITSM, document management, identity. Built once, used by every agent that needs them. This is where most of the integration value actually lives.
Tier 3 — Partner and third-party
Partner APIs and paid third-party services, governed by their own commercial terms. We do not resell these — we connect them and manage the contract relationship transparently.
Tier 4 — Marketplace plugins
Published by others, installable by you, with the same evaluation and governance treatment as anything you built. A plugin is not trusted because it is in the marketplace.
The tools every agent needs before anyone writes a plugin
These are the capabilities that arrive with the platform and quietly remove the need for a custom build in a surprising number of agents.
Web browsing and content reading
A browser capability that retrieves network content for a given address, covering web pages, files and link reading, plus a link reader that extracts the main body text from a raw URL rather than the surrounding markup.
Query and extraction
A SQL capability that queries data with statements, and an OCR capability that recognises and extracts text from images — the difference between an agent that can read a screenshot and one that cannot.
Context and time
A time tool for the current date and time, an external knowledge base connector for systems that already hold your content, and academic retrieval across arXiv and Semantic Scholar for research-heavy agents.
Beyond the built-ins: an extensible catalogue
The plugin centre organises its catalogue into ten categories, which is a reasonable proxy for what enterprises actually ask for: logistics, news reading, science and education, life assistance, voice and video, image processing, text processing, tool efficiency, and web search, alongside general entertainment categories that rarely see enterprise use.
We deliberately do not quote a plugin count on this page. Catalogue figures differ between product versions, and a number that changes with the release cycle tells an architect nothing. What matters is whether the specific capability your workflow depends on is present, or can be reached as a custom plugin against the same API.
The escape hatches that are always available
HTTP request node
Call any REST API directly, for the cases a plugin does not cover.
Code block node
Python or JavaScript for custom logic, when a configuration is not enough.
Database module
Create, read, update and delete against a database — for persistent agent memory and business data interaction.
File parsing
Structured reading of documents as a tool, not only as knowledge-base material.
Turning an endpoint you already run into a tool an agent can use
The configuration surface is deliberately explicit. Nothing is hidden, because the point is that a person who understands the business domain — not only the code — can make their own system callable by an agent.
What you configure
- Plugin name and description — the description is what the agent reads when choosing a tool, so vague wording here produces vague tool selection later.
- API address and request method — the endpoint and the HTTP method, GET or POST and the rest.
- Request headers — including the header that carries the credential.
- Request parameter rules — each parameter's name, type, whether it is required, and a description of what it means.
- Output field mapping — a JSONPath expression per field, so the agent receives named values rather than an opaque response body.
Test online, then bind
Configuration comes with a Test action that issues the call and shows the mapped result against your own parameters. The intent is unglamorous and important: get the call and the mapping working before the plugin is attached to an agent, so that a failure during a live conversation is a business problem and not a configuration problem.
Authentication the plugin supports
Authentication is carried in a custom request header, which means the same mechanism accommodates every common enterprise pattern:
Bearer token
A short-lived token issued by your identity provider and passed as an Authorization header.
AK/SK
Access key and secret key for services that expect signed requests.
OAuth
Bearer credentials obtained from an OAuth flow you already operate.
Internal signing
Your own corporate signature scheme, for internal services that verify on your terms rather than the vendor's.
Our recommendation. Use short-lived tokens wherever the target system supports them, and keep the secret out of the configuration. A static key pasted into a plugin header is a credential with no expiry, no rotation and no audit trail.
MCP works in both directions, and the second one is where the leverage is
The first direction gets you started fast. The second is what turns an agent into a component other systems can depend on.
- You already run the endpoint — it is exposed, not rebuilt
- The agent's identity and caller's identity are both carried
- Your existing authorisation rules apply unchanged
- The contract is documented and versioned like any API
- Rate limits and quotas are yours to set and enforced
- No new surface area to secure beyond what you already run
- Other systems can call your agent as if it were an endpoint
- Useful when a workflow in another system needs an agent's judgement
- Requires the same identity discipline in reverse
- Adds a latency dependency you must design around
- Cost per call becomes visible at the call site
- Rarely needed on a first project — build it when something demands it
MCP works in both directions, and that is the part that matters
Most agent platforms can call an external MCP server. Fewer can publish their own capabilities back out. The second direction is what turns a set of internal workflows into a shared capability that other teams' agents — and other vendors' agents — can consume without a bespoke integration.
The platform as MCP client
Your agents call external MCP servers as ordinary tools. Anything exposed by a server — internal services, a vendor's specialist capability, another team's agent — becomes callable inside your orchestration, with the same parameter discipline as a first-party plugin.
- One integration, many agents — a capability is registered once and inherited by every agent that needs it.
- Unified tool surface — external servers and native plugins appear to the agent through the same tool interface, so prompts do not fork.
- Gateway value — an MCP gateway in front of your estate is where you enforce access control, redact data and log calls, once, for everything behind it.
Your workflows, published as an MCP server
A workflow or agent you have already built and governed can be published as an MCP server, so that other agents consume it as a tool. The business logic, the retrieval, the approval rules and the audit trail stay exactly where they were — and the capability becomes reusable.
- Capability reuse — one well-built expense-claim workflow serves finance's own agent and the HR assistant that needs it.
- Cross-team sharing — a capability can be published across departmental boundaries without granting users direct access to the underlying systems.
- Shortest path to reuse — publishing an MCP server is far less work than a bespoke integration, and the consuming side needs no knowledge of your internals.
Why this is the shortest path. Capability reuse is normally solved by duplicating logic, by building a shared service, or by integrating one team at a time — each of which takes a programme. Publishing an MCP server is a configuration act that turns an asset you already own into a published interface. For enterprises with many internal teams and duplicated automation, that is usually the highest-leverage move available in the whole platform.
Do not rebuild what already works
Two questions come up in almost every first architecture review: what do we do with the agents we already bought, and how do we reach the systems that have no API? Both have an answer that avoids a rewrite.
Adopting external and in-house agents
Agents built on another platform — or built by your own team on a different stack — can be registered into a single unified entry point and scheduled alongside the agents you own. Support for the A2A protocol, and for SSE-based conversational agents, means the integration point is the agent protocol rather than a bespoke connector written for one vendor.
For an enterprise that has already invested in AI assets, this is the difference between consolidating and starting over. We will always recommend consolidation, because the accumulated behaviour, prompt logic and evaluation history inside an existing agent is far more expensive to recreate than to register — and far more likely to be subtly wrong if you do.
Reaching your systems of record
OA, CRM, ERP, ticketing, travel, calendar and to-do systems are integrated through APIs, the Web SDK, or MCP servers — the same three routes used elsewhere on the platform, so there is one integration discipline to learn rather than three.
Notification push
Push results into your enterprise collaboration platform so that an agent's action reaches the person who has to act, without them watching a console.
Approval hand-off
Where a workflow needs a human decision, the approval can be raised in the OA system and the agent resumes when the answer arrives.
Shared knowledge source
Channels can be bound to a common knowledge source with per-channel parameters for first-token latency, message timeout ceilings and long-content segmentation, so answers do not contradict across surfaces.
Bring us your integration list, not your requirements document
Seven answers we need for each system. If you can answer them, we can usually give you a date. If you cannot answer 6 and 7, that is the real conversation.
- System name and what it is the system of record for.
- Does it have a real API, and does it have one you are permitted to use?
- What authentication does it use, and who owns those credentials?
- What is the read path, and what is the write path? Are they the same team?
- What does its audit log already capture?
- How many concurrent callers can it take before it degrades?
- Who signs off when the agent writes to it?
Where the agent runs, and how callers prove who they are
Publishing is a set of surfaces rather than a single one. Authentication has to hold across all of them, because the same agent will be reached from a channel, an embedded widget and a back-end service.
| Surface | How it is used | Typical fit |
|---|---|---|
| IM channel, one-click publish | Publish the agent to enterprise messaging and personal messaging channels, including official accounts and mini-programmes, with the channel's own identity in front of the user. | Internal assistants and employee-facing services |
| Web SDK embedding | A JavaScript bundle embedded in a site, app or H5 page, initialised with an application identifier, a channel and a user identifier. | Customer-facing chat on your own property |
| REST API | Back-end invocation by your own services, with SSE streaming so the caller can render tokens as they arrive rather than waiting for the full answer. | Server-to-server workflows and embedded features |
| Web SDK / H5 terminal | A terminal form factor built for tablets and fixed devices on a production line. | Industrial and frontline deployments |
| MCP server publication | The agent or workflow is exposed as an MCP server for other agents to call as a tool. | Capability sharing across teams and platforms |
| A2A access | The agent is addressed through the agent-to-agent protocol for coordinated scheduling with other agents. | Multi-agent estates and cross-vendor collaboration |
| Private client distribution | A client deployed inside your own network for environments where external distribution is not acceptable. | Regulated and internal-only estates |
Keys and tokens
A published application yields an API key, and callers authenticate with a bearer token in the Authorization header.
Your identity system, connected
SSO and OAuth integration against the enterprise directory, so the agent receives the caller's department, position and line manager without anyone writing authentication logic.
Webhooks and network controls
Inbound callbacks are signature-verified in a request header, and IP allowlists can be applied to internal interfaces and to the outbound addresses your channels use.
One user, one identity, everywhere. A single user identifier follows the same person across channels, so the employee who asked something in a messaging client, in an embedded widget and in a back-end service has one history and one set of permissions. Multi-account and multi-device users get consistent behaviour rather than contradictory answers.
Where the agent runs, and how callers prove who they are
Dropping the caller's identity at the integration boundary is the most common serious defect we find in enterprise agent estates. It is invisible until an incident.
Agent identity
Who the agent is, which service account it acts as, and what that account is permitted.
Caller identity
Who asked the agent to act. Carried through, never dropped at the integration boundary.
Delegation record
The pair, logged together. This is what an auditor asks for: not what the agent did, but who caused it.
Authorisation decision
Evaluated at the tool, against the pair — not against the agent alone.
Audit entry
Recorded with the pair, the arguments, the result, and the authorisation decision.
What we will not claim
Two things on this page are deliberately described without a product surface, because pretending otherwise would only move the problem into your architecture review.
Per-channel rate limiting is yours to build. There is no clear productised interface for configuring rate limits and quotas at the level of a published channel. We do not pretend otherwise in a proposal. In practice this means a gateway of your own in front of the published endpoints, sized to your traffic profile, with the platform acting as the agent runtime behind it.
Custom plugins need structured responses. The API behind a custom plugin is expected to return a structured payload that the configured JSONPath expressions can read. Responses that are irregular, deeply nested in a bespoke format, or partly non-structured need a conversion layer in front of the endpoint before the plugin can be relied on. We will tell you this during design rather than at integration.
Also worth saying plainly
- Catalogue size is not a design argument. We would rather specify the handful of tools your workflow needs, and know exactly what each one costs, than quote a number that changes with the release cycle.
- Tool quality depends on the target. A connector is only as good as the service behind it. We will not present a third-party integration as equivalent to a first-party one.
- MCP does not remove the integration work. It removes bespoke connector code, not the need to agree ownership, data classification and failure behaviour with whoever owns the target system.
- Per-channel and per-user quotas should be designed with finance in mind. We can help you model the traffic; we will not invent a default limit on your behalf.
What we will not claim
We do not claim any integration is instant. Systems with real APIs and real contracts take real time. We do not claim we can connect to something that has no programmatic interface without building one, and we will not pretend a screen-scraping wrapper is the same thing.
Five questions that settle whether you need this
Five yes-or-no answers. If you cannot answer the first three, the capability is not your bottleneck yet.
- Can you name the specific workflow this serves — not the department?
- Can you name the person accountable when it is wrong?
- Can you show me historical cases where a human did this task, so we can build an evaluation set?
- Can you tell me what this capability explicitly will not do?
- Can you tell me what it costs per task, and how you would reduce that cost?
What the first ninety days look like
The same shape on every capability. The content differs; the checkpoints do not.
| By day 30 | By day 60 | By day 90 |
|---|---|---|
| Baseline captured on your metric | Workflow running with a named approver | Metric moved, against the baseline you did not choose |
| Scope boundary documented — including what it may not do | Evaluation harness re-running on every change | Decision log reviewed by your risk function |
| Historical cases assembled for testing | Training delivered, completion in the LMS | Next workflow scoped from what we learned |
| Data lineage for every source the agent reads | Cost per task measured and modelled | Evidence pack complete and accepted |
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Bring us your integration list, not your requirements document.
A working session on the systems you already run: which need a custom plugin, which should be an MCP server, and which are worth leaving behind. You will leave with a tiering decision per system and an honest view of the work.