Azure AI Language + MCP：为AI Agent接入NLP能力实战

在 Azure 上构建一个只会闲聊的 AI Agent 并不难，难的是让它真正读懂文本——识别语言、抽取实体、定位敏感信息。YouTube 上这期实操视频展示了如何用 Azure AI Language 配合 MCP 协议，把一整套 NLP 能力挂载到 Microsoft Foundry 的 Agent 上。整个流程踩了一个不小的坑，也正好暴露了当前 MCP 工具链在区域支持上的现实约束。

整体架构：三个资源串起一条链路

这套方案的核心思路是把 Azure AI Language 当作一个 MCP Server，通过 Foundry Agent 的 Tool 机制调用它。需要的资源有三块：

• Azure AI Language 资源：承载语言检测、实体抽取、PII 识别等 NLP 能力
• Microsoft Foundry 资源：托管 Agent 本体和模型部署
• 角色权限：Language 资源和 Foundry 资源都需要给执行者分配 Foundry User 角色，否则在 Foundry 门户里创建 Agent 时按钮会直接锁死

权限这一步容易被跳过。实际操作中，两个资源各自进入 Access Control → Role Assignments，添加 Foundry User 并指定成员身份，缺一个都会导致后续步骤卡住。

部署模型与创建 Agent

权限配好之后，进入 Foundry 门户。默认创建 Agent 会选用 GPT-5，但视频作者选择先手动部署一个更轻量的模型——GPT-4.1 nano，理由很直接：这是该系列里最小的模型，部署快、成本低，足够验证工具调用链路是否通畅。

部署完成后进入 Agents → 新建 Agent，命名为 language agent interaction，交互模式选文本，创建后直接打开 Playground。此时 Agent 已经带着模型跑起来了，但还没有任何 NLP 能力。

通过 MCP 挂载 Azure AI Language 工具

这是整条链路的关键一步。在 Agent 的 Tools 面板里选择 Add Tool → Catalog，找到 Azure Language in Foundry Tools，创建连接。需要填的参数包括：

• Foundry 资源名称
• 认证方式：这里选 Key-based，从 Language 资源的 Keys and Endpoints 页面复制一个 Key 粘贴进去

连接成功后，Language 服务下的各项能力会以独立工具的形式出现在 Agent 中——detect language、extract named entities、PII detection、entity linking 等。每个工具在调用时都需要用户手动确认一次，这算是当前 MCP 工具调用的安全机制。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底提出并开源的协议标准，目标是统一大语言模型与外部工具、数据源之间的交互方式。在 MCP 出现之前，每个 Agent 框架（LangChain、Semantic Kernel、Foundry 等）都有一套自己的工具描述格式，云厂商要把 PaaS 能力接进不同 Agent 就得重复适配。MCP 把这件事抽象成 Client 与 Server 两端：Server 用标准化的 schema 声明自己暴露哪些工具、每个工具接受什么参数，Client（即 Agent 运行时）负责发现这些工具并把调用请求转发过去。

它借鉴了 LSP（Language Server Protocol）的思路——LSP 统一了编辑器和语言分析器之间的接口，MCP 则统一了 Agent 和外部能力之间的接口。所以你会看到 Azure AI Language 被封装成一个 MCP Server 后，detect language、extract named entities、PII detection 这些原本是 REST API 端点的能力，自动变成了 Agent 可以按语义挑选的工具。云厂商的 PaaS 能力以 MCP Server 形式重新打包，本质上是把"写代码调用 API"变成"让模型自己决定调不调、调哪个"。

踩坑：区域不支持导致 MCP 枚举失败

作者在 South India 区域首次尝试时遇到了明确的报错：

The remote MCP server rejected the request while enumerating tools. Response status code does not indicate success: region not supported.

这意味着 Azure AI Language 的 MCP Server 并非在所有区域都可用。作者的解决办法是在 East US 重建全部资源——Foundry 资源、Language 资源、模型部署和角色分配全部重做一遍。

这个细节值得单独拎出来说。Azure AI Language 的 MCP 工具目前对区域有硬性要求，创建资源前如果不确认区域支持情况，后面整条链路都跑不通。视频里作者也提到，他在开始时并不知道哪个区域支持，是试错之后才定位到 East US。

MCP 工具枚举（tool enumeration） 是 Agent 接入 MCP Server 后的第一步握手动作：Client 向 Server 发起 tools/list 请求，Server 返回自己支持的全部工具清单及其 JSON Schema。只有枚举成功，Agent 才知道有哪些工具可用、该用什么参数格式去调用。所以这里的报错"rejected the request while enumerating tools"并不是某次具体调用失败，而是连"你有哪些工具"这一步都没走通——意味着该区域的 MCP Server 端点根本不可达或未部署。

Azure 的 PaaS 服务长期存在区域功能差异，新能力通常先在少数区域 GA（Generally Available，正式可用），其余区域要么处于 Preview，要么完全不开放。MCP Server 属于较新的接入层，覆盖区域自然更窄。更麻烦的是这种限制不会在创建资源时就提示——Language 资源在 South India 可以正常创建、可以调用 REST API，但它的 MCP 端点不存在，问题只会在 Agent 尝试枚举工具时才暴露。这也是作者建议先确认区域支持情况的原因：资源能建出来不等于 MCP 链路能跑通。

实测效果：实体抽取跑通

切换到 East US 后，作者用一句测试文本验证了链路：

Satya Nadella is the CEO of Microsoft.

Agent 自动连接到 MCP Server，请求批准 extract named entities 函数调用，批准后返回结果：Satya Nadella（Person）、CEO（Job Title）、Microsoft（Organization）。

整个流程从用户输入到结构化输出完全由 Agent 自主编排工具完成。除了实体抽取，detect language、PII detection、entity linking 等 NLP 任务都可以用同样方式调用。

这套方案适合谁

如果你的 Agent 需要处理多语言文本、从非结构化内容中抽取结构化信息，或者做合规层面的敏感信息识别，Azure AI Language + MCP 的组合提供了一条相对标准化的路径。工具的粒度足够细，每个 NLP 能力独立暴露，Agent 可以根据用户意图自行选择调用哪一个。

代价是配置链路较长——两个资源的权限分配、Key 认证、区域选择，每一步都有踩坑空间。区域限制尤其需要注意，建议在 East US 等已验证支持的区域起步，确认链路通畅后再考虑迁移。

MCP 作为 Agent 与外部工具之间的协议层正在快速成熟，Azure AI Language 的工具化封装是一个值得关注的信号：云厂商的 PaaS 能力正在以 MCP Server 的形式重新打包，Agent 生态的工具供给会越来越丰富。