Foundry Agents MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| agents_list_agentsA | List all available agents and workflows in the Azure AI Foundry project. Returns a formatted list of published agents including their IDs, models, descriptions, and available tools/capabilities. Example prompts:
|
| agents_invoke_agentA | Invoke an agent or workflow with a task and optional context. Creates a new conversation thread, submits the task, and returns an invocation ID that can be used with agents_get_invocation_status and agents_get_invocation_result. |
| agents_get_invocation_statusB | Check the status of an agent or workflow invocation. |
| agents_get_invocation_resultA | Retrieve the text or file results from a completed agent or workflow invocation. |
| index_create_project_log_indexA | Create the project log search index in Azure AI Search. Sets up the index schema including vector search capabilities for semantic similarity search on the context field. The schema supports: title, type, customer_name, short_summary, context (+ embedding vector), project_name, tags, reference_url, architecture, creation_date, modified_date. Safe to call if the index already exists – it will return a confirmation without modifying the existing index. Example prompts:
|
| index_ingest_project_logB | Ingest a project log entry into the Azure AI Search index with vector embeddings. Generates a vector embedding for the context field and stores the complete project log entry. Creates the index automatically if it does not exist. |
| search_vector_dbA | Search the project vector database using semantic similarity. Generates a vector embedding for the query and returns the most similar documents from the Azure AI Search index. |
| search_add_to_vector_dbA | Add a new document to the project vector database. Generates a vector embedding for the content and stores the document in the Azure AI Search index for future semantic searches. |
| workflows_list_sample_workflowsA | List the available sample workflow and agent definitions. Returns the names, locations, and descriptions of the built-in declarative
YAML files in Example prompts:
|
| workflows_run_project_log_workflowA | Run the full project-log ingestion workflow for a Microsoft customer story. This workflow sequentially invokes two declarative agents:
The combined result is stored as a single entry in the Azure AI Search project-log vector index. If |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
The agents_* and workflows_* tools are fairly distinguishable, but there's notable overlap between index_ingest_project_log and search_add_to_vector_db — both add a document to the same vector index. search_vector_db vs index_* tools are clear, but the ingest/add duplication causes potential misselection.
The server mixes three namespaces: agents_*, index_*, and search_*, each with a verb_noun pattern. However, search_vector_db and search_add_to_vector_db break consistency — one names the action (search) while the other uses search_ as a namespace prefix, so search_* doesn't consistently mean a namespace or an action.
10 tools is a reasonable and well-scoped count for a server handling both agent invocation and vector-database search. Each tool has a clear role in the two primary workflows, though the redundant ingest/add tools pad the count slightly.
The agent workflow covers list/invoke/status/result, which is complete for async invocation. The vector DB side has create-index, ingest, add, and search. Minor gaps exist — there's no delete or update for vector documents, and the result retrieval is separated from status with no explicit error-handling tool — but core lifecycle needs are met.