Add pre-execution trust verification hook for MCP tool calls

[vdineshk]

Problem

When DocsGPT connects to an MCP server to execute a tool call, there is currently no framework-level hook to verify the server's trustworthiness before execution. This means a misconfigured or malicious MCP server could execute arbitrary operations without any pre-flight safety check.

As MCP adoption grows and users connect to third-party servers, this becomes an increasingly important security surface.

Proposal

Add a configurable middleware/hook point that runs before any MCP tool execution:

# Example: pluggable trust verification
class TrustVerifier(Protocol):
    async def verify(self, server_uri: str) -> TrustResult: ...

# Users bring their own verification backend
app = DocsGPT(
    trust_verifier=MyCustomVerifier()  # Pluggable
)

The hook would:

1. Receive the MCP server URI before the tool call executes
2. Return a pass/fail/warn result
3. Allow the framework to block, warn, or proceed based on the result

Benefits

• Framework-agnostic: users choose their own verification backend (local policy, external API, allowlist, etc.)
• Opt-in: doesn't break existing workflows — only activates when configured
• Extensible: works with any trust scoring service, SBOM validator, or local policy engine
• Security-first: addresses the growing concern around MCP server supply chain risks

References

• OWASP MCP Security Cheatsheet
• Anthropic MCP Security Notifications
• Similar patterns exist in middleware architectures (Express.js middleware, Django middleware, etc.)

[ABISHEAK-std]

Hi @vdineshk ,

Proposed Fix: Framework-Level Tool Execution Trust Hook

1. Problem:
When DocsGPT calls ANY tool (MCP, API, custom), there's no security gate between the decision to execute and actual execution. Misconfigured or malicious tools run without pre-flight validation.

2. Solution:
Add an optional, pluggable TrustVerifier (Protocol-based) that runs before tool execution. Users bring their own verification logic allowlist, webhooks, SBOM scanning, rate limiting, etc. If no verifier is configured, system works as-is (backward compatible).

Before tool.execute_action() in ToolExecutor, we call middleware that passes rich context (TrustContext: tool_name, server_uri, arguments, user_id, timestamp) to the verifier. Verifier returns verdict (ALLOWED, BLOCKED, or WARNED). Fail-open by default with logging.

I would like to work on this issue and will try to submit my PR as soon as possible , could you assign this issue to me..