Tool Governance and MCP Host Playbook

Languages: English · 中文

With three tools, passing a function list to the model may work. With dozens of tools, the failure pattern changes: capabilities are scattered, every request exposes too much, the model picks the wrong tool, permissions are rejected too late, and MCP integration leaves the Host responsibility unclear.

This playbook separates registration, activation, planning, and execution. MCP becomes a capability source; business governance stays with the Host.

Four Layers

Layer	Owns	Agently capability
Capability registration	Available actions, argument schema, description, side-effect level	Actions / Action Runtime
Scoped activation	Which capabilities the model sees in this run	Agent definition, policy, runtime options
Planning and selection	Which capability to call and what arguments to fill	Output schema, Action Runtime, TriggerFlow chunk
Normalized execution	Local function, HTTP, MCP, sandbox under one result shape	Action Executor, ExecutionEnvironment

Once these layers are separate, adding a new capability source does not require rewriting the planner.

Keep the Boundaries Separate

Boundary	Better shape	Common consequence when mixed
Registration != activation	Register the full catalog; expose a scoped subset per identity, scenario, and risk	Full tool exposure causes wrong selection and privilege leakage
Activation != planning	Activation selects candidates; planning chooses one and fills args	Policy and model reasoning get buried in prompt text
Planning != execution	Planner does not know whether the capability is local, HTTP, MCP, or sandboxed	Changing capability source rewrites planning logic
Execution != business judgment	Executor calls capability and returns structured result/logs	Execution layer secretly owns business path

Build a Capability Catalog First

Each callable capability should at least record:

Field	Purpose
id / name	Stable identity for logs and audit
description	Helps the model decide when to use it
input schema	Parameter types, required fields, business meaning
side effect level	read / write / exec; drives approval and policy
executor	Local function, MCP call, HTTP adapter, or sandbox task
owner / source	Debugging and version ownership

Descriptions are not just human README text. They should help the model distinguish when to use the capability and when not to.

Do Not Expose Every Tool Every Time

Full exposure increases token cost, wrong selection, and audit confusion. A better route:

user request + identity + route
  -> candidate actions
  -> policy filter
  -> model-visible action surface
  -> action logs + audit

Read-only queries, business writes, script execution, and high-risk approval should not appear in one undifferentiated list.

MCP Has Three Roles

Role	Responsibility
Server	Expose tools, resources, or prompts; define schema; execute capability
Client	Manage connection, handshake, discovery, forwarding
Host	Decide which capability the model may see, how identity is injected, what is redacted, how calls are audited

Agently can mount MCP tools into Action Runtime so the model sees them like other callable capabilities. The enterprise application still owns Host governance.

Four Host Responsibilities

Responsibility	Why it matters
Identity propagation	The end user logged into your app, not the MCP server. Capability-side permissions and audit need that identity.
Visible capability scoping	Different roles should see different tools. Do not expose everything and rely on server rejection.
Result redaction	Sensitive fields should be removed or aggregated before they enter model context.
Call audit	Server audit says what resource was accessed; Host audit says why the tool was exposed and selected.

MCP and Skills

Question	MCP	Skills
How to expose external capabilities in a standard way	Owns	Does not own
How to approach a class of tasks	Does not own	Owns
Tool args schema and result shape	Owns	Can reference
Multi-step guidance, resources, scripts, output templates	Can be a dependency	Owns
Lifecycle	Server / Client / Host	Select / load / map to runtime capabilities

A Skill can depend on MCP tools. The Skill describes behavior; MCP supplies executable capability. Keep the lifecycles separate.

Recommended Path

1. Convert one local function into an Action and inspect action logs.
2. Centralize tool description, schema, side-effect level, and owner.
3. Scope the action surface by scenario or identity.
4. Add MCP server as another capability source.
5. Use ExecutionEnvironment when the MCP server, browser, database, or sandbox needs lifecycle management.
6. Use TriggerFlow when tool calls sit inside a multi-stage task.
7. Put high-risk writes, batch execution, and external side effects behind approval or fail-closed paths.

Common Misuse

Pattern	Consequence
Tools scattered in prompts and handlers	No one can answer what capabilities the system has
Every request exposes every tool	Wrong selection, privilege leakage, high cost
Planner depends on whether a tool is MCP or local	Changing source rewrites planning logic
Executor makes business routing decisions	Calling and process logic become hard to test
MCP integration is treated as permission completion	MCP solves connection; Host still owns governance
Server-side redaction replaces Host-side redaction	Sensitive data may already have entered model context
Skill is treated as MCP or Tool replacement	Behavior asset and capability layer get mixed

See Also

• Actions Overview
• MCP
• Execution Environment
• Enterprise Agent Capability Boundaries
• Skills Executor