Overview

What is MCP?

Model Context Protocol (MCP) is an open standard that enables AI models to seamlessly discover and execute external tools at runtime. Instead of being limited to text generation, AI models can interact with filesystems, search the web, query databases, and execute custom business logic through external MCP servers.

DeepIntShield provides a comprehensive MCP integration that goes beyond simple tool execution:

• MCP Client: Connect to any MCP-compatible server (filesystem tools, web search, databases, etc.)
• MCP Server: Expose your connected tools to external MCP clients (like Claude Desktop)
• Agent Mode: Autonomous tool execution with a configurable eligibility allow-list
• Code Mode: Let AI write and execute sandboxed Starlark to orchestrate multiple tools
• Python SDK: Execute tools directly and adapt normalized tool definitions for OpenAI, Anthropic, and LangChain

Note

The MCP Registry, connection health, Agent Mode, and Code Mode are available through the gateway core on every plan; there is no separate MCP-console or Code Mode entitlement gate. Creating or changing a connection requires a workspace admin, tenant owner/admin, or system admin. Server-count quotas are Community 1, Team 25, Business 50, and Enterprise / Enterprise VPC unlimited.

Security-First Design

Note

By default, DeepIntShield does not automatically execute model-suggested tool calls. Your application makes an explicit execution request and decides whether to add its own human review. Agent Mode can make selected tools eligible for an autonomous loop through tools_to_auto_execute; that allow-list is not itself an authorization verdict or approval.

When Agentic-New GAF is enabled, JSON-RPC /mcp, explicit tool execution, Agent Mode, and nested Code Mode calls all use the same server-side canonical decision point. Every actual invocation requires an exact Allow; catalogue visibility and tools_to_auto_execute never grant execution, and shadow mode does not bypass a Deny or pending approval.

Key Security Principles:

Principle	Description
Explicit Execution	Tool calls from LLMs are suggestions only - execution requires separate API call
Granular Control	Filter tools per-request, per-client, or per-virtual-key
Opt-in Auto-execution	Agent Mode eligibility must be configured, and canonical authorization still decides every call
Stateless Design	Each API call is independent - your app controls conversation state

Key Capabilities

Connect to MCP Servers

Connect to external MCP servers via STDIO, HTTP, or SSE protocols with automatic retry logic

Open →

OAuth Authentication

Strict MCP OAuth 2.1 with issuer binding, live refresh, reauthorization, and revocation; OAuth 2.0 remains available for compatibility

Open →

Delegated Authentication

Exchange a caller token and isolate resource-bound Streamable HTTP sessions

Open →

Tool Execution

Execute tools with full control over approval and conversation flow

Open →

Agent Mode

Enable autonomous tool execution with a configurable eligibility allow-list

Open →

Code Mode

Let AI write sandboxed Starlark to orchestrate multiple tools in one request

Open →

Connection Resilience

Transient failures recover on their own and disconnected servers reconnect automatically

Open →

MCP Gateway URL

Expose DeepIntShield as an MCP server for Claude Desktop and other clients

Open →

Tool Filtering

Control which tools are available per request or per virtual key

Open →

Python SDK

Call tools, discover clients, normalize results, and build provider-specific tool schemas with shield.mcp.

Open →

Two roles you can use

DeepIntShield works as an MCP client (you connect it to external tool servers) and, in the Gateway deployment, as an MCP server (you expose your aggregated tools to external clients like Claude Desktop).

• To connect to external tool servers, see Connecting to MCP Servers.
• To expose your tools to Claude Desktop / Cursor, see MCP Gateway URL.

The default tool-calling workflow

By default DeepIntShield does not execute tool calls automatically - you stay in control. The workflow you implement is:

1. POST /v1/chat/completions - the model returns tool-call suggestions (not executed).
2. Review the tool calls - apply your security rules or ask the user to approve.
3. POST /v1/mcp/tool/execute - execute the approved tool calls.
4. POST /v1/chat/completions - continue the conversation with the tool results.

This gives your application an explicit review point before execution. With canonical GAF enabled, the server independently classifies the Registry action, records the decision, and requires an exact Command Authority approval for write-like or unknown actions. See Tool Execution for the end-to-end code. To let eligible tools enter an autonomous loop, enable Agent Mode; GAF still decides every call.

When to use Code Mode

If you connect 3+ MCP servers, evaluate Code Mode. It keeps the model’s context compact because the model can write one short script instead of round-tripping through every tool definition. The cost and latency savings shown in the Code Mode example are workload-specific, not a service-level guarantee. Benchmark classic and Code Mode with your tools, prompts, model, concurrency, and sandbox limits before choosing a default.

---

Next Steps

Connect to MCP Servers

Set up your first MCP client connection →

Choose Authentication (if needed)

Learn about header-based, OAuth 2.1, and OAuth 2.0 compatibility authentication →

Enable Code Mode (for 3+ servers)

Evaluate Code Mode cost and latency →

Execute Tools

Learn the tool execution workflow →

Enable Agent Mode

Configure autonomous tool execution →