The Azure Language MCP server

This card is where two earlier ideas meet: the Language service from card 25 and the Model Context Protocol from card 15. The server exposes Azure Language's text-analytics capabilities as tools an agent can call.

That sentence is worth memorising as written, because "exposes Azure Language text-analytics capabilities as MCP tools for agents" is the answer to any question asking what its primary role is.

How a prompt reaches a language skill

1. The agent receives the prompt — an ordinary user message.
2. It matches the tool description. Tool selection is description-matching, so good instructions improve it.
3. Approval. The default is never to auto-approve. In code, you must handle the approval event.
4. The Language skill runs, and the result returns to the agent, which answers.

Step two is the fourth appearance of the same principle: descriptions drive selection. By this point in the guide it should feel less like a fact to memorise and more like how the platform works.

Why offload to it at all

Speed, cost and determinism on narrow natural-language tasks.

A language model could do the same work. It would be slower, more expensive and less repeatable. This is card 25's judgement applied one layer up — the agent is capable of reasoning its way to an answer, and for a well-defined task like detecting a language or extracting entities, reasoning is the expensive way to get a result you could have had deterministically.

Configuration

• It uses the resource endpoint — not the project endpoint. Worth flagging, because most of this exam pushes you toward the project endpoint.
• Authentication is by key or credential.
• It is created once per resource and reused across agents.
• It can be remote, through the Foundry Tool Catalog, or local and self-hosted. The feature is in preview.

Related prebuilt agents

• Intent Routing — conversational language understanding plus custom question answering.
• Exact Question Answering — custom question answering.

The client pattern is the familiar one: AIProjectClient, then the OpenAI client, then responses.create(model=agent_name). Third time this sequence has appeared, after cards 8 and 16.

The trap

Approval defaults to never auto-approve.

In the portal you can approve once, or configure which tools are allowed. In code, if you do not handle the approval event, the tool call silently returns nothing — and the agent answers as though the tool did not exist.

That last clause is what makes it dangerous. It does not error, and it does not stay silent. It produces a confident answer built on no tool output at all. Card 15 flagged the same failure on the general MCP surface; it is worth seeing twice, because the symptom looks like a model quality problem and is actually an unhandled event.