AI Tool-Call and MCP Telemetry Requirements

Tool-call evidence begins before the request

A tool server receives an operation and credentials. By that point, an application has already assembled context, selected a tool, constructed arguments, and applied or skipped policy. Server logs alone cannot explain the full decision path.

The Model Context Protocol, or MCP, standardizes ways for AI applications to discover and invoke tools and access contextual resources. Detection should distinguish protocol message, agent decision, authorization, tool execution, and target-side effect.

Record the initiating subject and session, application, agent and trace identifiers, MCP client and server identity, tool name and version, requested operation, target, authorization context, policy and confirmation result, start and completion time, outcome, and returned data classification.

Describe arguments without creating a second secret store

Arguments can contain file paths, recipient addresses, queries, personal data, credentials, customer records, or complete messages. Logging every value improves reconstruction while creating a concentrated disclosure risk.

Define an argument schema per tool. Retain operation, parameter names, object class, sensitivity, destination category, counts, and protected stable identifiers where these support detection. Redact secret values, tokenize approved identifiers, or keep full content behind controlled retrieval when justified.

Hashes support exact comparison but do not anonymize small or guessable values. Truncation can hide the part that changes meaning. State what representation preserves and which investigations require authorized deeper access.

Tool discovery and capability change matter too

Agents can discover tools, schemas, and resources before invoking them. A new tool server, changed description, expanded parameter, or modified capability can alter what an agent is able or likely to do.

Record server registration, identity, transport, certificate or integrity context, tool catalog and schema versions, capability changes, approvals, and which agents can see them. Treat descriptions as untrusted input because they can influence selection and argument construction.

A call to an approved tool can still be unsafe after the server implementation or schema changes. Relate runtime calls to the catalog version and policy that evaluated them.

Trace retries, streaming, and nested calls honestly

A tool call may stream partial results, retry after timeout, launch a job, or invoke another service. Counting each protocol message as a separate action inflates activity; merging them can hide partial side effects.

Use request, attempt, job, parent, and result identifiers with clear semantics. Record idempotency keys and whether a retry could repeat a consequential action. Preserve cancellation, timeout, partial completion, and target-side outcome separately.

Do not assume a completed MCP response proves the external resource reached the intended state. Target audit can confirm the effect. When that evidence is unavailable, report request and tool response rather than successful business action.

Connect tool evidence to a bounded detection decision

Useful analytics compare tool use with the intended task, initiating authority, approved capability, target sensitivity, confirmation rule, and observed outcome. A rare tool is not automatically malicious. A common tool can be dangerous when used outside scope or in an unexpected sequence.

The alert should carry the complete authority chain, tool and schema version, protected argument summary, target, policy and confirmation, result state, trace relations, and known logging gaps. Apply privacy-safe AI logging to any retained prompts, retrieval, memory, or outputs.

State the fact and assessment separately: the agent called this tool with this authority and changed this resource; the action appears inconsistent with the initiating task and policy. Model motive and user intent remain uncertain.