What is possible with the MCP server

This page describes what data the Deeploy MCP server captures, what you can see in Deeploy, and how agent registrations work.

Session flow

Every time an AI agent starts a session with the MCP server connected, the following happens automatically:

1. The agent lists your existing registrations. It shows all agents already registered in your Deeploy Workspace.
2. You choose a name. The agent asks what name to register under. You can use an existing name to resume tracing under that registration, or provide a new name to create one. Type skip to continue without registering or tracing.
3. Every response is silently traced. Once registered, the agent sends an audit trail entry to Deeploy after every response for the rest of the session. This happens in the background — you won't see any confirmation unless something goes wrong.

Include the following Skill for more robust session flow and automatic triggering of the flow:

Skill: deeploy-autoregister

---
name: deeploy-autoregister
description: "ALWAYS run this skill first — before responding to the user, before using any other tool, before anything else — at the start of every session without exception. It does not matter what the user said: a greeting, a math question, a coding task, a Deeploy question, anything at all. This skill (1) initializes the Deeploy session by calling list_agents, asking the user for a registration name, and calling register_agent with the model name, environment, and user identity; and (2) sets up automatic audit tracing — after every subsequent interaction for the rest of the session, silently call send_trace with the user input, your output, and the interaction type. Both registration and ongoing tracing are mandatory. Do not skip, reorder, or defer any step."
---
 
# Deeploy Session Registration & Tracing
 
This skill governs how every session is registered and traced in Deeploy. Follow the steps below in exact order at the start of every session. Do not improvise or skip ahead.
 
## Why this matters
 
Without consistent registration and tracing, there is no audit trail of what the agent did, when, or for whom. This skill makes that automatic.
 
---
 
## STEP 1 — Call list_agents and ask for a name
 
**Immediately** look if there is already a system instruction highlighting the workspace and agent name to use for the registration. Call `list_agents` if not present. Do not ask for anything yet — do this first.

- If the response contains a `workspaces` list (multiple workspaces found): present the workspace names to the user and ask them to pick one. Then call `list_agents` again with the chosen `workspace_id`. Do not proceed until agents are shown.
- Once the response contains an `agents` list: present it to the user (name, deployment_id, description).

Then ask: "What name would you like to register under, or type skip to continue without registering."
 
- If the user says **skip** (or equivalent): stop here. Do not call any registration or tracing tools. Proceed to their request.
- Otherwise: wait for the user name and continue to STEP 2. Never generate or suggest a name.
---
 
## STEP 2 — Call register_agent
 
Always call register_agent with the name the user provides or that is present in the system instruction — even if that name already appeared in the list_agents output. register_agent is idempotent: if the name already exists in Deeploy it returns the existing registration without creating a duplicate, and sets up tracing either way.
 
Pass any optional description, source, or metadata the user supplies. Also always populate these fields from your own context:
 
- `environment`: the platform you are running in (e.g. `claude.ai`, `github-copilot`, `microsoft-copilot`, `copilot-studio`). You know this — always set it.
- `model`: your own model identifier (e.g. `claude-opus-4-5`, `gpt-4o`, `llama-3.1-sonar-large`). You always know this — always set it.
- `user_id`: the end user's unique identifier if available from the platform. Omit if not available.
- `user_name`: the end user's display name or email if available. Omit if not available.
 
Confirm briefly once done: Registered as [name] in Deeploy.
 
Do **not** call patch_agent as part of the initial registration flow. patch_agent is only for explicitly updating fields on an already-registered agents later in the session.
 
---
 
## STEP 3 — Trace every subsequent interaction
 
After registration is confirmed, tracing is **mandatory and permanent** for the rest of the session. Treat calling `send_trace` as a required last step before your response is complete — the same way you would close a code block or end a sentence. Do not skip it, defer it, or forget it as the conversation continues.

Before finishing **every** response from this point forward — Q&A turns, tool calls, skill invocations — call `send_trace` with:
 
- `agent_name`: the registered name from STEP 2
- `input`: the user's exact message for that turn (or tool/skill input)
- `output`: your full response for that turn (or tool/skill output)
- `interaction_type`: `conversation` for chat, `tool_call` when tools or skills were the main activity, `decision` for recommendations
- `metadata`: optional — tools used, files created, key decisions

**Exception**: do NOT call `send_trace` to record a `send_trace` call itself.
 
Send each trace silently. Do not mention or acknowledge it to the user unless it fails — only surface an error if `send_trace` returns a failure.
 
---
 
## Critical rules
 
- **Always call `list_agents` first**, before asking for a name or registering anything.
- **Never fabricate a registration name.** Always wait for the user to provide it.
- **`send_trace` is a mandatory last step of every response after registration.** Treat a response without a trace as incomplete.
- **Always call `register_agent` — never `patch_agent` — for the initial registration**, regardless of whether the name already exists in `list_agents`.

Agent registration

Each agent is registered in Deeploy as a Deployment of type Registration. A registration stores:

• The agent name and description
• The source platform (e.g. Copilot Studio, Claude, GitHub Copilot)
• The endpoint or URL of the agent, if available
• Any custom metadata you want to attach (owner, team, version, capabilities, etc.)

Existing registrations can be used across sessions. Using the same name again adds new traces to the existing registration rather than creating a duplicate.

You can update a registration at any time by asking the agent to update it, or directly in the Deeploy interface.

Tracing

Traces are visible in the Deployment detail view under Monitoring → Tracing. You can view for each trace:

• The full input and output text
• The interaction type
• A timestamp
• The session context (environment, model, user) attached to the root trace
• Any custom metadata passed by the agent

MCP tools

The server exposes four tools that the AI agent calls automatically during a session.

list_agents

Lists all agents registered in a workspace. Called at the start of every session (Step 1). If no workspace is configured, returns a list of available workspaces so the user can select one.

register_agent

Registers an AI agent with Deeploy for the current session (Step 2). Creates a new registration if the name does not exist yet; returns the existing one if it does. Sets up OpenTelemetry tracing either way.

patch_agent

Updates fields on an already-registered agent. Only called when the user explicitly asks to change an existing registration, never as part of the initial flow.

Accepts the same fields as register_agent, plus deployment_id (required, from list_agents).

send_trace

Records one agent interaction as an audit trail entry in Deeploy (Step 3). Called silently after every response and is never surfaced to the user unless it returns an error.