2025Agentic AI · MCPIn development

Knowledge Layer & MCP Agent

A reusable enterprise knowledge layer exposed through MCP, so Copilot, custom apps, and future Fabric agents can consume the same grounded KPI, schema, and product context through one governed tool surface.

MCPAzure AI SearchAzure AI FoundryFunction Apps
headline impact
In dev
MCP knowledge layer · governed tool surface for product, KPI, and schema context
my role
Role
Lead developer · architecture, backend, MCP tool layer, agent flow, and Azure integration
status
Status
In development · not production yet
demo
In development
Development-stage trace only
the problem

What was broken

Enterprise knowledge sits scattered across Excel files, decks, KPI dictionaries, schema references, semantic relationships, and product-specific documentation. Different consumers need the same trusted business context, but without a unified access layer every team rebuilds its own retrieval flow, producing duplicated work, inconsistent answers, and weak grounding.

my approach

How I built it

I am building a Knowledge Layer Asset organised into three areas: Knowledge Layer Content Creation, Knowledge Layer Store, and an MCP Layer. Curated business knowledge — global definitions, KPI dictionary, table and column dictionary, semantic relationships, and product-specific assets like Market Mirror and MMR — is indexed into Azure AI Search across dedicated indexes. On top sits a Remote MCP Server hosted on Azure Function Apps, authenticated through OAuth 2.0 / Microsoft Entra ID inbound and UAMI / Managed Identity outbound to Azure AI Foundry and Azure AI Search. The MCP tool drives a Product Identifier → Schema Identifier → KPI Identifier agent chain that returns grounded context back to the client. This is currently in development and should not be represented as production.

why this way

The reasoning

MCP gives the knowledge layer a single, versioned contract. Any client can speak the same protocol and get the same grounded answer with the same auth, logging, and guardrails. Splitting product, schema, and KPI identification into focused agents keeps each step independently testable and lets the index registry scale to new products without touching consumers.

architecture

How the pieces fit

Clients
Copilot Studio AgentCustom Web AppFuture Fabric Data Agent
MCP Layer
Remote MCP Server on Azure Function AppsTool: ask_market_mirror_agentOAuth 2.0 · Entra IDManaged Identity → Foundry / Search
Agent Layer (Azure AI Foundry)
Product IdentifierSchema IdentifierKPI Identifier
Knowledge Store (Azure AI Search)
Product Index RegistryKPI IndexTable & Column IndexDefinition IndexSemantic Index
Knowledge Assets
Excel-based knowledge filesFabric-stored knowledgeProduct-specific dictionaries
what I built

Key components

  • 01Remote MCP server hosted on Azure Function Apps with Managed Identity for backend access
  • 02Azure AI Search indexing across KPI, schema, definition, semantic, and product registries
  • 03Azure AI Foundry agents for product, schema, and KPI identification
  • 04Product Index Registry resolves the right product-specific indexes dynamically
  • 05Microsoft Entra ID OAuth 2.0 for inbound auth, UAMI for backend access to Foundry and Search
  • 06Client integration through MCP tool ask_market_mirror_agent
  • 07Designed for future Fabric data agent consumption through the same MCP contract
what I used

Tech stack

Agentic AI
Azure AI FoundryAzure OpenAIMCPMulti-Agent OrchestrationRAG
Backend
PythonFastAPIAsyncIOPydantic
Cloud
Azure Function AppsAzure AI SearchAzure Key VaultAzure Monitor
Security
Microsoft Entra IDManaged IdentityOAuth 2.0RBACPrivate Endpoints
development walkthrough

Development trace

A development-stage trace showing the intended agent flow. This is not represented as production.

dev trace · ask_market_mirror_agent
press play to watch the trace