Unity and DevelopmentUnity and codeAdvanced~8 min

MCP Observability: From Tool Calls to Task Success

Snapshot

~90 sec

MCP observability must connect a protocol request, tool call, developer task, approval, and verification result without exposing secrets. Record latency, retries, error class, bounded payload size, progress, cancellation, and evidence. A successful tool response proves transport and execution, not that the game-development task is correct.

You will learn

Correlate protocol requests, tool calls, and application tasks without treating one identifier as universal.
Separate tool-call success from independently verified task success.
Use MCP logging, progress, and cancellation alongside application telemetry.
Bound observability cost through redaction, sampling, and rate limits.

Target outcome

You can design a trace that explains what happened, what was approved, what it cost to move through the system, and whether the result was actually verified.

01
Capture six kinds of evidence
- Correlation
  Link the MCP request id to application-generated tool-call and task ids without assuming MCP defines a universal task trace.
- Timing and retries
  Record start, finish, latency, timeout, retry count, and whether the operation was safe to retry.
- Error class
  Separate transport, protocol, validation, permission, tool-execution, cancellation, and verification failures.
- Payload and context size
  Measure bounded bytes, records, or items returned. Token and model-context cost remains host and model specific.
- Approval evidence
  Record the decision, reviewed capability and argument summary, actor class, and time without copying sensitive content.
- Verification evidence
  Record the independent diff, test, visible state, or build-profile check that confirms or rejects task success.
02
Carry correlation from request to verified outcome
This invented trace follows one prefab proposal. Protocol events and application evidence share references, but each retains its own meaning.
1. MCP request
  Record request id, method, server identity, start time, and redacted argument shape.
  starts
2. Tool-call span
  Attach an application tool-call id, latency, retry count, payload size, and error class.
  serves
3. Developer task
  Link the call to the invented PrefabReview task and its narrow intended outcome.
  requires for write
4. Approval evidence
  Record that one reviewed prefab field and target were approved, without logging the full prompt.
  permits one attempt
5. Tool result
  Record success, failure, cancellation, and bounded result metadata.
  does not replace
6. Verification result
  Attach the exact-diff and targeted-test verdict as separate evidence.
This invented trace follows one prefab proposal. Protocol events and application evidence share references, but each retains its own meaning.
Reading order
1. MCP request
  Record request id, method, server identity, start time, and redacted argument shape.
2. Tool-call span
  Attach an application tool-call id, latency, retry count, payload size, and error class.
3. Developer task
  Link the call to the invented PrefabReview task and its narrow intended outcome.
4. Approval evidence
  Record that one reviewed prefab field and target were approved, without logging the full prompt.
5. Tool result
  Record success, failure, cancellation, and bounded result metadata.
6. Verification result
  Attach the exact-diff and targeted-test verdict as separate evidence.
Connection explanations
1. MCP request → Tool-call span (starts)
  The protocol request id locates the exchange, while the application span adds operational measurements.
2. Tool-call span → Developer task (serves)
  A tool call gains meaning only when linked to the developer outcome it is intended to support.
3. Developer task → Approval evidence (requires for write)
  A consequential task records a distinct approval rather than inferring authority from correlation.
4. Approval evidence → Tool result (permits one attempt)
  Approval covers the reviewed attempt, target, and arguments, not an unlimited series of retries.
5. Tool result → Verification result (does not replace)
  A successful response can still produce the wrong project state, so verification remains a separate verdict.

Do not collapse three success levels

Approach	What it proves	Invented Unity example	Required next evidence
Protocol successThe client received a well-formed response for the matching request.	Transport, protocol handling, and response correlation completed.	A console-read request returns a structured result for the disposable PracticeRoom project.	Check that the returned slice matches the visible Unity Console and requested filters.
Tool-call successThe server reports that the selected operation ran without a tool error.	The server believes the operation executed, subject to its implementation and result contract.	An approved generic prefab field update returns a success result and changed-asset identifier.	Inspect the prefab and exact version-control diff rather than accepting the result text.
Verified task successIndependent evidence shows that the intended developer outcome holds.	The change is correct within the reviewed scope and passes its acceptance checks.	The expected prefab field alone changed, the targeted Unity test passes, and no unrelated asset diff exists.	Attach the verification references to the task report and preserve the redacted trace.

Continue next
Production Hardening for MCP Servers
Use observed failure and outcome signals to harden the boundaries that matter in production.
04
Invented long read: progress and cancellation remain observable
A generic asset inventory can take long enough to report progress. MCP progress and cancellation signals help coordinate the request, while application telemetry records bounded operational detail.
States
1. Request accepted
  The client starts a read-only inventory with a correlation id and an optional progress token.
  Observable output: One active request is visible with zero retries and no result payload yet.
2. Progress reported
  The server sends bounded progress updates without streaming asset contents into logs.
  Observable output: The trace shows current progress, elapsed time, and a rate-limited update count.
3. Cancellation requested
  The developer cancels after realizing that the selected directory is broader than intended.
  Observable output: The cancellation signal is correlated with the active request and classified separately from failure.
4. Work stopped or result ignored
  The server stops when possible, and the client no longer treats a late response as task evidence.
  Observable output: The trace closes as cancelled with no retry, no mutation, and no verified task success.
Transitions
1. 01
  Request accepted → Progress reported
  Input
  The server begins the bounded inventory.
  Effect
  Progress notifications update the correlated operation without creating new tasks.
  Result
  The operator can distinguish healthy work from a stalled request.
2. 02
  Progress reported → Cancellation requested
  Input
  The human identifies excessive scope and requests cancellation.
  Effect
  The trace records the request and prevents an automatic retry.
  Result
  The operation is no longer expected to produce usable task evidence.
3. 03
  Cancellation requested → Work stopped or result ignored
  Input
  The server stops after receiving cancellation or the client discards a late result.
  Effect
  Resources are released when possible and the task remains unverified.
  Result
  Cancellation is visible as an intentional outcome rather than a generic tool error.
Warning
Logging is a protocol utility, not a secret archive or token meter
Use MCP logging at an appropriate negotiated level, and rate-limit or sample repetitive events. Redact credentials, authorization headers, personal data, prompts, file contents, and sensitive tool arguments before storage. Record bounded byte, item, and latency measures. Token usage and context cost depend on the host, model, message construction, and caching behavior; they are not a standard MCP log field unless the surrounding application deliberately adds and defines them.
Diagnose a false success
An invented prefab-write request returns success in 120 ms, but the targeted test fails and the diff shows a second asset changed. Which status should the developer report, and what trace evidence is needed?
Expected reasoning
Report protocol and tool-call success but verified task failure. Link the request, tool-call, task, approval, exact target and redacted arguments, latency, retry count, result metadata, failing targeted-test evidence, and unexpected diff. Do not overwrite the verification verdict with the successful tool response, and do not log project contents or secrets while preserving the correlation.

Go deeper

MCP 2025-11-25 specification: LoggingCurrent server-to-client structured logging levels and notification contract.
MCP 2025-11-25 specification: ProgressCurrent progress token and notification semantics for long-running requests.
MCP 2025-11-25 specification: Tasks (experimental)Experimental task lifecycle and polling model; do not treat it as a stable production dependency without compatibility guards.
MCP 2025-11-25 specification: CancellationCurrent request cancellation notifications used to distinguish stopped work from success or tool failure.

You will learn

Target outcome

Capture six kinds of evidence

Correlation

Timing and retries

Error class

Payload and context size

Approval evidence

Verification evidence

MCP request

Tool-call span

Developer task

Approval evidence

Tool result

Verification result

Reading order

Connection explanations

Do not collapse three success levels

States

Request accepted

Progress reported

Cancellation requested

Work stopped or result ignored

Transitions

Request accepted → Progress reported

Progress reported → Cancellation requested

Cancellation requested → Work stopped or result ignored

Diagnose a false success

Go deeper