| name | tool-intercept-logger |
| model | sonnet |
| description | Produces structured OTEL-compatible log entries and a session summary (call counts, success rate, cost, top tools by cost and frequency) for all tool executions within a session. Use when: "log tool calls for this session", "debug unexpected tool selection", "audit token cost by tool", "validate a new MCP integration", "build a session summary for handoff". |
| license | proprietary |
| category | system-health |
| triggers | ["log tool calls for this session","debug unexpected tool selection","audit token cost by tool","validate a new MCP integration","build a session summary for handoff"] |
| tier | 1 |
| agents | ["primary"] |
| tool_dependencies | ["file_system"] |
| inputs | [{"name":"session_context","type":"string","description":"Session identifier or context for the logging run","required":false}] |
| outputs | [{"name":"session_log","type":"string","description":"Structured OTEL-compatible log entries and session summary with call counts, success rate, cost, and top tools"}] |
I. Philosophy
You cannot improve what you cannot see. Tool call logging is not just
debugging infrastructure — it is the foundation of agent observability.
Understanding which tools are called, how often, at what cost, and with what
success rate is prerequisite knowledge for any meaningful performance
optimization or behavioral audit.
OTEL-compatible attribute naming ensures that logs produced here can be
consumed by any standards-compliant observability pipeline without translation.
Dual-layer storage (SQLite + OTEL) means the data is queryable locally and
exportable to external systems without re-instrumentation.
II. When to Use
Use this skill when:
- Starting a new session and establishing a baseline of tool call patterns
before any optimization work.
- Debugging unexpected agent behavior — especially looping, repeated calls,
or unexpected tool selections.
- Auditing token cost attributable to specific tools or namespaces.
- Validating that a new MCP server or tool integration is being called as
expected and returning correct results.
- Building a session summary for handoff to another agent or for human review.
Do not use this skill as a replacement for the agent-performance-report
skill. Tool intercept logging captures raw, per-call data during a session.
Performance reporting aggregates historical span data across sessions. Use
both in sequence when doing a comprehensive system health review.
III. Workflow
Step 1 — Define logging scope.
Before any tool executions begin (or at the point logging is activated), define
the scope of capture. Three scope modes are supported:
all — capture every tool execution in the current session regardless of
namespace or namenamespace — capture all tools matching a namespace prefix, e.g.,
mcp_by_dojo:* or gateway:*named — capture a specific list of tool names only
If scope is not specified by the user, default to all and note this in the
log header.
Step 2 — Capture pre-execution context.
For each tool execution that falls within scope, record the following before
the call is dispatched:
timestamp_start: <ISO 8601 with milliseconds>
llm.tool_name: <fully qualified tool name>
parameters: <sanitized argument map — redact any value matching patterns
for API keys, passwords, tokens, or PII>
estimated_tokens: <token estimate for input arguments>
node_id: <DAG node ID if this call is part of an orchestration plan>
dependencies: <list of node IDs this call depends on, if known>
