Add mock auth-bound MCP demo with trusted identity binding

[Codex]

Description

Demonstrates that the app—not the LLM—binds a trusted user identity to the MCP client so the server enforces authorization. Adds an isolated mock MCP server plus a demo script that shows authorized vs unauthorized tool calls.

client_info = Implementation(name="auth-binding-demo", version="1.0.0", user="alice@example.com")
async with ClientSession(read_stream, write_stream, client_info=client_info) as session:
    await session.call_tool("get_sensitive_data", arguments={"record_id": "vault-001"}, meta={"user": "alice@example.com"})

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code refactoring
• Performance improvement
• Test addition/improvement

Related Issues

Changes Made

• Mock MCP server (mock_auth_mcp.server) with in-memory users/permissions and tools get_my_data / get_sensitive_data that enforce identity-bound auth.
• ASGI wrapper with health/CORS and session-manager startup for Streamable HTTP plus README-style run/tunnel instructions.
• Demo script that binds identity via ClientSession.client_info and shows authorized vs unauthorized flows; added focused auth-resolution tests and wired test discovery.

Testing

• All existing tests pass
• Added new tests for new functionality
• Manually tested the changes
• Updated documentation

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Screenshots (if applicable)

Additional Context

Original prompt

Before you start
• Read Azure AI Foundry + MCP tool integration docs first.
• Look at my A2A server code to understand how Foundry calls are currently made.
• You do NOT need to fully run Foundry locally if credentials are missing — focus on a realistic mock aligned with how Foundry works.

Goal

Build a small isolated demo showing this pattern:

The application chooses a trusted user identity, and binds it to the MCP client when making an LLM call — so MCP authorization is enforced independently of anything the LLM says.

What to build

1. Mock MCP server
   • Create a new, isolated mock MCP server (don’t use existing one)
   • No database — use in-memory data
   • Include:
   • simple users list
   • simple permissions map
   • Add at least 2 tools, e.g.:
   • get_my_data
   • get_sensitive_data
   • Enforce authorization server-side using the user identity passed through the MCP session/request
   • Return clear errors for unauthorized access

2. Demo app flow

Create a small script or endpoint that:
• sets a trusted identity in code (e.g. "alice@example.com")
• initializes/configures an MCP client bound to that identity
• makes an LLM call (Foundry-style, based on repo patterns)
• allows the model to call MCP tools

Important:
• The user identity must come from the app code, NOT from the model output.

3. Show both cases
   • Authorized user → success
   • Unauthorized user → denied by MCP server

4. Public endpoint
   • MCP server needs to be publicly reachable
   • Use dev tunnels for this (totally fine for the demo)

Deliverables
• New mock MCP server code (isolated folder)
• Demo script / endpoint
• Short README explaining:
• where user identity is set
• how MCP client is bound to that user
• where authorization is enforced
• Clear run instructions

Key question this should answer

Can the app layer bind a trusted user identity to the MCP client during an LLM call, so MCP enforces auth regardless of what the LLM says?

Constraints
• Keep it minimal and readable
• Don’t overengineer
• Don’t modify production code heavily
• Prefer reusing existing repo patterns (especially A2A + Foundry call structure) unless changes are needed. Right now a2a foundry calls are simply retrieving an agent made in the foundry portal, you will probably need to either retrieve and modify the tool definitions, or create from scratch via code