When to use an MCP plugin
Use an MCP server plugin when:- an external system already publishes a maintained MCP tool contract;
- several RevoEngine Agents need the same governed integration;
- the remote catalogue changes independently and must be synchronized and reviewed;
- credentials must remain in RevoEngine Secrets rather than prompts or Agent configuration;
- read and write tools from one provider require different policies.
Configuration model
Use the generated Platform API reference for the exact create and update DTO. The administrative UI exposes the same lifecycle without requiring a handwritten payload.
Authentication and Secrets
Bearer tokens, basic-auth passwords, and sensitive custom headers must reference a RevoEngine Secret. A binding can follow the active Secret data revision or pin an explicit revision when controlled credential rollout requires it. Non-sensitive static header values are supported, but do not use that field to avoid Secret governance.Safe onboarding workflow
1
Create the connection definition
Select the transport, HTTPS endpoint, bounded timeout, authentication mode, and Secret bindings. Keep the plugin disabled for general use.
2
Test connectivity
Authenticate and initialize the remote server. A successful connection test proves reachability and handshake compatibility; it does not approve every discovered tool.
3
Synchronize the manifest
Fetch the remote tool catalogue and store the reviewed capability snapshot. Inspect new, removed, and changed schemas as an integration contract diff.
4
Apply default policy
Decide whether discovered tools are enabled or deferred by default. Start with read-oriented discovery and deny unexpected mutation capabilities.
5
Review per-tool overrides
Set aliases, mutation intent, reversibility, target scope, approval mode, and side-effect summaries for each admitted operation whose behavior differs from the default.
6
Enable and attach
Enable the plugin only after review, then attach it to the intended Assistant thread, Agent definition, Agent policy, or individual run.
7
Validate end to end
Run a read-only scenario, confirm evidence and output limits, then validate writes with explicit approval and a reversible test target.
Per-tool governance
Each discovered tool can override:- whether it is enabled;
- whether it is loaded immediately or deferred behind discovery;
- the local alias presented to the Agentic System;
- approval mode and safety tier;
- read, write, destructive, or external mutation intent;
- reversibility and affected target scope;
- a concise side-effect summary shown during review.
Manifest changes
Treat any of the following as a contract change:- a tool is added or removed;
- a name, description, or input schema changes;
- a read operation gains write behavior;
- required authentication or headers change;
- output size, latency, or external side effects materially change.