💥 Introducing JevEval: Jev-as-a-Judge for LLM evaluation. Read the post →
MCP

Multi-Turn MCP-Use

LLM-as-a-judge
Jev-as-a-judge
Multi-turn
Referenceless
Chatbot
Multimodal

The Multi-Turn MCP Use metric is a conversational metric that uses LLM-as-a-judge to evaluate how effectively an MCP based LLM agent makes use of the mcp servers it has access to. It evaluates the MCP primitives called as well as the arguments generated by the LLM app.

Required Arguments

To use the MultiTurnMCPUseMetric, you'll have to provide the following arguments when creating a ConversationalTestCase:

  • turns
  • mcp_servers

You will also need to provide mcp_tools_called, mcp_resources_called and mcp_prompts_called inside the turns whenever there is an MCP interaction in your agent's workflow. You can learn more about creating MCP test cases here.

You can learn more about how it is calculated here.

Usage

First, set the eval mode:

deepeval set-eval-mode llm         # LLM-as-a-judge (default)
deepeval set-eval-mode hybrid      # LLM extracts, Jev decides
deepeval set-eval-mode system_one  # Jev-as-a-judge, no LLM

The MultiTurnMCPUseMetric() can be used for end-to-end multi-turn evaluations of MCP based agents.

from deepeval.test_case import Turn, ConversationalTestCase, MCPServer
from deepeval.metrics import MultiTurnMCPUseMetric
from deepeval import evaluate

convo_test_case = ConversationalTestCase(
    turns=[Turn(role="...", content="..."), Turn(role="...", content="...")],
    mcp_servers=[MCPServer(...)]
)
metric = MultiTurnMCPUseMetric(threshold=0.5)

# To run metric as a standalone
# metric.measure(convo_test_case)
# print(metric.score, metric.reason)

evaluate(test_cases=[convo_test_case], metrics=[metric])

There are NINE optional parameters when creating a MultiTurnMCPUseMetric:

  • [Optional] threshold: a number representing the minimum passing threshold. Can also be set to None to run the metric in score-only mode. Defaulted to 0.5.
  • [Optional] model: a string specifying which of OpenAI's GPT models to use, OR any custom LLM model of type DeepEvalBaseLLM. Defaulted to gpt-5.4.
  • [Optional] include_reason: a boolean which when set to True, will include a reason for its evaluation score. Defaulted to True.
  • [Optional] strict_mode: a boolean which when set to True, enforces a binary metric score: 1 for perfection, 0 otherwise. It also overrides the current threshold and sets it to 1. Defaulted to False.
  • [Optional] async_mode: a boolean which when set to True, enables concurrent execution within the measure() method. Defaulted to True.

  • [Optional] verbose_mode: a boolean which when set to True, prints the intermediate steps used to calculate said metric to the console, as outlined in the How Is It Calculated section. Defaulted to False.
  • [Optional] flaky: a boolean which when set to True, marks the metric as flaky. Defaulted to False.
  • [Optional] system_one_model: the Jev model to use, as a string or a DeepEvalBaseSystemOneModel. Only used under hybrid or system_one eval_mode. Defaulted to jev-latest.
  • [Optional] eval_mode: llm, hybrid or system_one, choosing whether an LLM, Jev, or both judge. Defaulted to the configured eval mode (llm unless set).

As a standalone

You can also run the MultiTurnMCPUseMetric on a single test case as a standalone, one-off execution.

...

metric.measure(convo_test_case)
print(metric.score, metric.reason)

How Is It Calculated

You can change how the MultiTurnMCPUseMetric is calculated by setting the eval mode.

LLM-as-a-judge

The MultiTurnMCPUseMetric score is calculated according to the following equation:

MCP Use Score=AlignmentScore(Primitives Used, Primitives Available)Total Number of MCP Interactions\text{MCP Use Score} = \frac{\text{AlignmentScore(Primitives Used, Primitives Available)}}{\text{Total Number of MCP Interactions}}
  • The AlignmentScore is judged by an evaluation model based on which primitives were called and their generated arguments with respect to the task.
  • MCP Interactions are the number of times the LLM app uses the MCP server's capabilities.

Hybrid

Under the hybrid eval mode, the LLM still splits the conversation into tasks, but each task's primitive usage and argument correctness scores are rated by Jev, a System One model, on a scale mapped onto 0 to 1. The equation and the LLM-written final reason are unchanged. If a Jev call fails, the LLM makes that decision instead.

Jev-as-a-judge

Under the system_one eval mode, Jev judges the whole metric in one request. It is sent the whole conversation (with the MCP calls in each turn) and the available mcp_servers and asked three questions:

QuestionTypeWeight
In every assistant turn in turns, the MCP tools, resources and prompts called (mcp_tools_called, mcp_resources_called, mcp_prompts_called, or tools_called) are the right ones among those in mcp_servers for what the user asked, with no clearly better primitive missed and no unnecessary call.Noul2
Every MCP call in turns passes arguments that match that primitive's input schema in mcp_servers and carry the values the user asked for.Noul1
Across turns, how well does the assistant use the MCP servers in mcp_servers, in both the primitives chosen and the arguments passed, to serve the user's requests? (Wrong use → Correct use)Score1

Each answer becomes a value in [0,1][0, 1] and the score is their weighted mean. No LLM is called: the reason lists each answer with its probability, and metric.confidence reports how decisive Jev was.

FAQs

Should I reach for this over the single-turn MCP Use metric?
Use MultiTurnMCPUseMetric for one score over MCP usage spanning several turns. For a single input/actual_output, use single-turn MCPUseMetric on an LLMTestCase.
Where do the called primitives go in a ConversationalTestCase?
turns and mcp_servers go on the ConversationalTestCase, but mcp_tools_called, mcp_resources_called, and mcp_prompts_called live inside each turn, not at the top level.
One turn misused a tool — how do I find which turn dragged the score down?
One bad call lowers the averaged score. Enable verbose_mode to print per-interaction reasoning and pinpoint the offending turn.
Why is my score lower when the agent makes more MCP calls?
The denominator is total MCP interactions, so every extra call is held to the same alignment standard. Noisy or redundant calls pull the average down.

On this page