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 use a governed Vault binding. Instance Secrets remain supported. A remote MCP header can also bind a personal Secret or connected OAuth account, selected by the executing user’s explicit grant. Instance-owned connected accounts are available for shared service identity. An organization-scoped reference is recognized by the runtime when an organization grant has been provisioned; the current Vault screen does not offer self-service organization grants. The account owner first connects and consents at the provider, then grants the named value to this Agent plugin. A personal manifest is synchronized after the grant; if tools are still missing or stale, the authorized account can request another personal synchronization. Connecting or granting alone does not attach the plugin to a conversation. Plugin admission and per-tool approval remain separate. See Vault and connected accounts for the complete flow. 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 discovered operations deferred and under a conservative approval policy until their exact schemas and effects have been reviewed.
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.