Skip to main content
Glama

find_tool_calls

Search tool call history across agent sessions and subagents, filter by tool name, input/output content, errors, or session, and retrieve subagent cost details.

Instructions

Find every tool call across sessions, cross-agent by default.

redact=True (default) masks secrets in emitted record fields as [REDACTED_<TYPE>] and adds a redactions type→count dict when any replacement happened; redact=False returns raw content. Filters always match the RAW, pre-redaction text.

session scopes the scan to a single session uuid (or a list of uuids) — same semantics as the query facet. None = every session; a wide since/until with NO session therefore surfaces calls from unrelated sessions, so pin it when auditing one conversation.

Exactly one of tool_name (exact, case-insensitive) or tool_name_pattern (substring, case-insensitive) must be set.

Optional filters combine with AND: input_contains / output_contains (case-insensitive substring on the full, pre-cap input/output), output_excludes (drop records whose output contains it) and is_error (tri-state: None all, True failures only, False successes only). output_mode selects output truncation — "head"/"tail"/"smart"; None is adaptive ("smart" on errors, "head" otherwise). Each record also carries is_error_reliable (True only for Claude/OpenCode) plus the wrapper-aware classification: tool_kind (edit/write/read/bash/task/skill/mcp/ web/other) and tool_resolved — the real name under a Skill/Task/MCP wrapper (subagent type, skill name, or "<server>:<tool>"); None when there is no wrapper or the input carries no name signal.

A record whose call has a correlated result also carries tool_use_id — the join key back to a spawned subagent's own session (the child stores it as extra.spawn_tool_use_id). On a spawn (tool_kind="task") it additionally carries subagent: what the child COST — model (the model it actually resolved to, which may be a cheaper pinned tier than the parent's), agent_type (persona), tokens (EXACT billed usage, source="exact", full token-block shape), status, duration_ms, tool_uses. Honest gaps: a background spawn (status="async_launched", sidecar written before the run exists) reports its model with no tokens key — never a fabricated zero; its real cost and persona come from read_session(include_subagents=True)subagent_rollup.children. A record carrying several tool results drops the sidecar rather than billing it to the wrong subagent.

with_subagent_cost=True (opt-in) recovers exactly that for the spawn records here: each subagent sidecar is JOINED to the spawned child's own files, adding the persona (agent_type) from the child's agent-*.meta.json, the models it ran on, its EXACT billed tokens (source="exact", an estimate is never merged into the billing field) and child_uuid. So a background spawn — anonymous and price-less in the launch-time sidecar — becomes a named, priced row. The child is preferred over the sidecar, which stays the fallback for a child that cannot be joined (not yet on disk, meta corrupt): its tokens are then left absent, never zeroed. Default False reads no per-spawn child file (a cross-corpus scan does not pay the join).

Thin wrapper over :func:ai_r.find_tool_calls.find_tool_calls that translates the core ValueError contract into the {"error": "invalid_argument", "message": str(exc)} shape the MCP client expects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agentNo
limitNo
sinceNo
untilNo
redactNo
sessionNo
is_errorNo
tool_nameNo
output_modeNo
input_containsNo
output_containsNo
output_excludesNo
tool_name_patternNo
with_subagent_costNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses extensive behavioral traits: redaction masking with [REDACTED_<TYPE>] placeholders, filters matching raw pre-redaction text, tri-state is_error semantics, output_mode adaptive behavior, wrapper-aware classification, and honest subagent cost fallback gaps. This far exceeds typical transparency and fully describes edge cases without contradicting any structured metadata.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but each paragraph addresses a coherent behavioral aspect, and technical details are interwoven with usage rationale. It front-loads the core purpose and then organizes by parameter and edge case, making it navigable. Some length is justified given the tool's 14-parameter complexity, though a few sentences could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is self-contained, covering error translation, subagent cost join mechanics, fallback behaviors, and the presence of an output schema. It answers 'what happens if' for background spawns, corrupted metadata, and multi-result records. This goes beyond a typical tool description and fully prepares an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description adds deep meaning to most parameters: redact, session, tool_name/tool_name_pattern, input_contains/output_contains/output_excludes, is_error, output_mode, and with_subagent_cost. It even explains session semantics relative to since/until and hints at agent scope with 'cross-agent by default'. While 'limit' and 'agent' are not explicitly detailed, the description compensates overwhelmingly for the schema's silence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence uses a specific verb 'Find' and resource 'every tool call across sessions, cross-agent by default', clearly establishing the tool's scope. It distinguishes itself from siblings by focusing on tool calls and cross-agent scanning, which is not obvious from navigation-based tools like read_session or search_sessions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use context, such as pinning the session when auditing one conversation and opting into with_subagent_cost for subagent billing recovery. It does not explicitly name alternative tools or state when not to use this tool, but the context and filters give strong practical guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pro-target/ai-r'

If you have feedback or need assistance with the MCP directory API, please join our Discord server