Tool Injection & MCP: The Supply Chain Behind AI Agent Capabilities

Introduction

The previous article covered inbound CLI usage (scenario + skill). This piece addresses the outbound "supply chain": how tools, credentials, and authorization are injected into the agent runtime so the model can actually execute calls. The author uses a renovation crew analogy: tool list = toolbox, injection = bringing tools onsite, outbound = showing purchase order at the gate, unauthorized items = discovering unapproved materials mid-project.

Key Terminology

Tool List : capabilities actually visible and callable by the agent at runtime.

Injection : pulling the list and credentials from the platform into the container process before chat starts.

Outbound : the runtime segment that calls external tools/upstream APIs.

External Capability Layer : unified MCP/OpenAPI gateway that verifies tickets and forwards requests.

Unauthorized Items : entries present in the list but lacking completed authorization.

Platform Capability : policy-configured capabilities shipped with the release, belonging to the agent itself.

Personal Capability : caller's own MCP config or credentials, effective only for that user.

Cross-contamination (串盘) : personal credentials landing on a shared readable path, effectively public.

Tool Loop : the runtime cycle of model selects tool → calls → feeds result back.

01 | Tools Are Not Prompt Appendices

Four verification points:

Photos ≠ tools : describing tools in the prompt doesn't give the process legitimate capability.

Toolbox must reach the site : lists in release notes don't count; they must be pulled into the process.

Purchase order required at the gate : no ticket → upstream rejects with 401.

Unapproved materials caught early : discovering missing approval on day three wastes prior work.

A typical incident: all tool calls returned 401. Ops restarted the gateway (no fix), then prompt engineering was blamed. Root cause: new MCP service authorization incomplete; outbound headers carried no ticket.

Seven-Step Outbound Call Flow

(Illustrated in diagram) The flow traverses: runtime → injection → tool selection → outbound request → gateway ticket verification → upstream → response → feed back to model.

Four Common Scenes & Misdiagnoses

Scene A : Web has tools, IDE doesn't. Symptom: "models differ". Misdiagnosis: change model ID. Reality: host injection paths diverge, pulling different lists.

Scene B : All tools 401. Symptom: "gateway down". Misdiagnosis: restart gateway. Reality: invalid/missing ticket; outbound headers lack identity.

Scene C : Neighbor can call my service. Symptom: "no login". Misdiagnosis: add login. Reality: personal config on shared path; file permissions precede gateway.

Scene D : First round works, third round explodes. Symptom: "upstream unstable". Misdiagnosis: add timeout/retry. Reality: unauthorized items not gated at chat start; buried mid tool loop.

Supply chain holds only when: list enters process, outbound verifies tickets, unauthorized items intercepted early, personal credentials isolated.

02 | Prompt Words Describe Tools But Cannot Supply Blood

Three Layers of Disconnect

List not in process : definitions live in docs/policy UI; runtime pulls nothing at chat start. Long system prompts waste context; outbound still lacks credentials.

Outbound lacks identity : process knows tool name but gateway sees no ticket or someone else's ticket. Worse: tickets stored in shareable plaintext configs.

Auth state detached from execution state : user clicks approve but runtime uses stale cache; unauthorized items already in list, not intercepted at start. Collaboration adds risk: shared configs turn authorization into "whoever writes to shared file wins".

Architectural Comparison (Steal vs Reject)

Prompt-only tools : steal "fast demo"; reject "no real outbound, no audit".

Hardcoded in-process plugins : steal "controllable"; reject "hard multi-tenant, hard host migration".

MCP standard + unified gateway : steal "ecosystem & auth convergence"; reject "treat gateway as dumb reverse proxy, forget identity".

Per-host private protocols : steal "short-term flexibility"; reject "lists never align".

03 | Register, Inject, Outbound, Authorize: Four-Step Loop

Capability Layer (What) : defines which MCP/OpenAPI, scope ownership, pre-auth requirements → makes "what this agent can do" understandable.

Supply Layer (How) : injection timing, encrypted storage/retrieval, gateway ticket verification, failure codes → makes list effective in process and outbound legal.

Diagram shows four segments chained: capability registry → injection → gateway verification → authorization gating.

04 | Injection: Making Runtime Truly See Tools

Challenge

Config complete in portal, empty in container.

Solution

At chat start (or pre-warm), runtime pulls tool config visible to that agent + that caller , hands to SDK/CLI process. Host forms differ (headless vs IDE), so visible lists may differ; fetch key must carry full scope. Forbid "single global config file for whole platform".

Implementation Sketch

// TypeScript
// Guarantee: same agent, different caller/host can see different lists
type ToolScope = {
  agentId: string;
  callerId: string; // resolved real caller
  hostKind: "headless" | "ide";
};

async function loadTools(scope: ToolScope) {
  return await catalog.fetchToolBundle(scope);
}

# Python
# Guarantee: forbid global config serving everyone
def load_tools(agent_id: str, caller_id: str, host_kind: str):
    return catalog.fetch_tool_bundle(agent_id, caller_id, host_kind)

Platform vs Personal Capabilities

Platform/Agent-bound : configured in policy UI & release artifacts. Risk: over-permissioned; stale lists linger after release.

Personal MCP / Personal tickets : configured by caller. Risk: cross-contamination — landing in shared workspace in plaintext.

Collaboration disks are multi-user mounted; personal config must land on per-user isolated paths , secrets encrypted at rest, decrypted on-demand at injection. Analogy: worker leaving house keys in hallway — hallway cameras don't help; keys belong in personal toolbox.

Boundary : injection success ≠ outbound success; ticket and gateway verification remain.

05 | Outbound: Gateway Verifies Tickets, Tickets & Unauthorized Gating

Challenge

Tool calls degrading to "container direct-to-upstream" breaks identity and audit together.

Solution

All outbound traverses External Capability Layer (MCP/OpenAPI gateway): verify ticket, resolve identity, forward upstream. Runtime pulls "unauthorized items list" before chat; policy decides block or degrade with warning.

Ticket Sources & Discipline

Platform-issued call tickets : for automation & IDE calling gateway. Discipline: encrypt at rest, transmit in header, logs keep only fingerprint (length + last few chars).

User-side business tickets : for third-party/business APIs. Discipline: independent encrypted fields; display triggers masking.

OAuth exchange auths : for upstreams requiring consent page. Discipline: consent page → exchange → persist; don't spin up a shadow gateway.

Logs are leakage hotspots; tickets must never appear in plaintext logs.

Authorization Gate Implementation

// TypeScript
// Guarantee: unauthorized items not a mid-loop surprise
type AuthGate = { unauthorizedIds: string[] };

function beforeChat(gate: AuthGate, mode: "block" | "warn") {
  if (gate.unauthorizedIds.length === 0) return "ok";
  return mode === "block" ? "block_with_guide" : "warn_and_continue";
}

# Python
# Guarantee: gating happens before chat, not after first error
def before_chat(unauthorized_ids: list[str], mode: str) -> str:
    if not unauthorized_ids:
        return "ok"
    return "block_with_guide" if mode == "block" else "warn_and_continue"

If authorization only happens at user consent moment and not at chat-start gate, tool accidents become "intermittent". Analogy: material approval must finish before groundbreaking, not on day three.

Risk Profiles Demand Classifiers

Some services allow platform-managed silent tickets; some require explicit user confirmation; some only allow manual paste. Risk profiles differ → runtime/host must have a classifier to decide silent ticket eligibility. Exact wording irrelevant; mechanism mandatory.

Boundary : gateway verifies "who calls", not "can result write to someone else's directory" — that's workspace ACL/sandbox (see security deep-dive).

06 | Two Acceptance Scenarios

Scenario A: Web UI Calls Platform Tools

Path: conversation → runtime → inject agent tool list → tool call → gateway verify ticket → upstream.

Decision point: A) list only in release notes, runtime doesn't pull, relies on model "memory". B) pull at every chat/pre-warm; failure reports "config not injected" not "model sucks". Choose B . List is data, not model memory.

Scenario B: IDE Uses Personal Tools, Auth Incomplete

Path: IDE host → inject including personal items → chat-start gate detects unauthorized → guide auth/exchange → resume.

Decision point: A) allow first, wait for 401 then popup. B) intercept/warn at chat start, ensure personal config never written to shared plaintext path. Choose B . 401 mid-loop wastes user context rounds; problem existed from start.

Integration with "Life of a Conversation" Acceptance

Runtime ready : can chat → this article adds tool list injected.

Outbound : — → adds gateway ticket verification passes.

Authorization : — → adds unauthorized items gating matches policy.

07 | Supply Chain Cost & Selection

Three Breakthroughs

Quantified efficiency : tool failure debugging shifts from "guess model" to "check injection / ticket / auth", detours drastically reduced (mechanism comparison).

Capability sink : business side understands "what agent can do" from bound list, not mystic prompts.

Pattern upgrade : from "plug model in" to "supply blood to runtime" — upcoming container runtime & four security domains all hang on injection & outbound discipline.

Five-Dimension Selection Matrix

Real outbound : Prompt-only ✗, Hardcoded ✓, MCP+Gateway ✓, Per-host ✓

Multi-tenant : Prompt-only ✗, Hardcoded ✗, MCP+Gateway ✓, Per-host ✗

Host alignment : Prompt-only ✗, Hardcoded △, MCP+Gateway ✓, Per-host ✗

Security audit : Prompt-only ✗, Hardcoded △, MCP+Gateway ✓, Per-host ✗ (broken)

Recommendation : Prompt-only → demo only; Hardcoded → legacy understandable; MCP+Gateway → default ; Per-host → reject as end state.

08 | Where Not to Apply & Four Pitfalls

Applicability

Applicable : multi-tool, multi-entry, audit-required agent platforms; upstreams requiring OAuth/Token.

Not applicable : single-machine local function call demos; no-outbound pure in-memory tools.

Pitfall 1: Treat Gateway as Dumb Reverse Proxy

Temptation : connect path first, add identity later. Wrong fix : long-term no ticket verification, pretend network isolation equals security. Right fix : ticket verification is gateway's primary job; reverse proxy is just the means.

Pitfall 2: Personal Tickets in Shared Plaintext

IDE reads same config for convenience → keys placed in collaboration dir → anyone mounting can read. Once file exists, gateway verification can't help — ticket already public. Correct: per-user isolated path, encrypted at rest, decrypt at injection moment.

Pitfall 3: Unauthorized Items as Mid-Loop Exceptions

Temptation : simplest implementation, get flow working first. Wrong fix : fails at round N with 401, user waited rounds. Right fix : pull unauthorized list at chat start, block or explicit warn.

Pitfall 4: Each Host Maintains Own List

Web one set, IDE another, CLI another; release rhythms differ → lists never align. Source of truth must centralize in platform/orchestration; hosts only decide presentation & confirmation UX — align capability, not skin.

Maturity Levels (L1/L2/L3)

L1 : logs distinguish "not injected / 401 / upstream 5xx".

L2 : chat-start auth gating, personal path isolation.

L3 : default ticket modes, gateway verification policy changes.

Summary

Ability to work relies on supply chain : register list → runtime inject → outbound verify ticket → auth loop closed.

Prompt is not a tool system : model recognizing tool name ≠ process having legal capability.

Gateway's primary job is identity + forwarding , not naked reverse proxy.

Unauthorized items blocked at chat-start gate , not buried mid tool loop.

Personal capabilities must isolate ; shared-disk plaintext credentials are time bombs.

Hosts can differ in presentation , but list truth source must unify.

Capability comes from the registry, credentials from the vault — neither should live in the model's memory.

Next article: Agent Runtime Inside Containers — after tools can inject, how connections reuse, how rounds avoid pile-up, how cancellation truly stops clean.