Description
Every DeepReport cycle that invokes the agenticworkflows MCP logs tool without a workflow_name filter times out client-side before the tool returns — this has recurred across many prior cycles (worked around each time by falling back to in-window discussion reports, never previously filed as its own bug). Root-caused this cycle: pkg/cli/mcp_tools_privileged.go gives unfiltered ("all workflows") logs queries a defaultMCPLogsMinTimeoutMinutesAllWorkflows = 5 minute server-side floor (with defaultMCPLogsToolCount = 100 runs by default), because scanning across every workflow and reading artifacts genuinely takes that long. But deep-report.md's Step 2 ("Gather Workflow Intelligence") gives no guidance to scope the call with a workflow_name or small count, so the agent typically invokes it unscoped and only waits ~50-60s (a typical foreground tool-call budget) — far short of the 5-minute floor the tool itself expects to need.
Reproduced live this cycle: agenticworkflows logs with a -6h window (no workflow filter) returned only MCP keepalive pings for 50s with no final result, identical to the pattern noted in at least 2 prior cycles' briefings (e.g. #65643, and the 2026-09-07T~18:32Z cycle recorded in deep-report's own repo-memory).
Expected Impact
Unblocks DeepReport's own fleet-wide success-rate/token-usage/firewall-activity checks (currently silently skipped nearly every cycle in favor of less-direct discussion-report signals), and documents the real expected latency for any other agent/workflow calling this MCP tool without a workflow filter.
Suggested Fix
Update .github/workflows/deep-report.md Step 2 instructions to either: (a) scope agenticworkflows logs calls with a workflow_name filter or a small count so the call stays within the faster default timeout tier, or (b) explicitly budget for the documented 5-minute floor (e.g. run the call with a longer/background-tolerant invocation) when an unfiltered fleet-wide query is actually wanted. Optionally also note this latency floor in the tool's description/agentic-workflows skill docs so other workflows don't hit the same surprise.
Suggested Agent
deep-report itself (prompt/doc change only — no Go code change needed) or a documentation-focused agent via .github/skills/agentic-workflows/SKILL.md.
Estimated Effort
Quick (< 1 hour) — prompt/doc wording change.
Data Source
DeepReport Intelligence Briefing — 2026-10-05 cycle (incremental, baseline #65643). Root cause confirmed via direct read of pkg/cli/mcp_tools_privileged.go (defaultMCPLogsMinTimeoutMinutesAllWorkflows, defaultMCPLogsToolCount, effectiveMCPLogsToolTimeoutMinutes) cross-referenced against .github/workflows/deep-report.md's Step 2 prompt text (no scoping guidance present) and this cycle's live reproduction.
Generated by 🔬 Deep Report · claude · agent · 216.9 AIC · ⌖ 8.14 AIC · ⊞ 7.1K · ◷
Description
Every DeepReport cycle that invokes the
agenticworkflowsMCPlogstool without aworkflow_namefilter times out client-side before the tool returns — this has recurred across many prior cycles (worked around each time by falling back to in-window discussion reports, never previously filed as its own bug). Root-caused this cycle:pkg/cli/mcp_tools_privileged.gogives unfiltered ("all workflows")logsqueries adefaultMCPLogsMinTimeoutMinutesAllWorkflows = 5minute server-side floor (withdefaultMCPLogsToolCount = 100runs by default), because scanning across every workflow and reading artifacts genuinely takes that long. Butdeep-report.md's Step 2 ("Gather Workflow Intelligence") gives no guidance to scope the call with aworkflow_nameor smallcount, so the agent typically invokes it unscoped and only waits ~50-60s (a typical foreground tool-call budget) — far short of the 5-minute floor the tool itself expects to need.Reproduced live this cycle:
agenticworkflows logswith a-6hwindow (no workflow filter) returned only MCP keepalive pings for 50s with no final result, identical to the pattern noted in at least 2 prior cycles' briefings (e.g. #65643, and the 2026-09-07T~18:32Z cycle recorded in deep-report's own repo-memory).Expected Impact
Unblocks DeepReport's own fleet-wide success-rate/token-usage/firewall-activity checks (currently silently skipped nearly every cycle in favor of less-direct discussion-report signals), and documents the real expected latency for any other agent/workflow calling this MCP tool without a workflow filter.
Suggested Fix
Update
.github/workflows/deep-report.mdStep 2 instructions to either: (a) scopeagenticworkflows logscalls with aworkflow_namefilter or a smallcountso the call stays within the faster default timeout tier, or (b) explicitly budget for the documented 5-minute floor (e.g. run the call with a longer/background-tolerant invocation) when an unfiltered fleet-wide query is actually wanted. Optionally also note this latency floor in the tool's description/agentic-workflowsskill docs so other workflows don't hit the same surprise.Suggested Agent
deep-reportitself (prompt/doc change only — no Go code change needed) or a documentation-focused agent via.github/skills/agentic-workflows/SKILL.md.Estimated Effort
Quick (< 1 hour) — prompt/doc wording change.
Data Source
DeepReport Intelligence Briefing — 2026-10-05 cycle (incremental, baseline #65643). Root cause confirmed via direct read of
pkg/cli/mcp_tools_privileged.go(defaultMCPLogsMinTimeoutMinutesAllWorkflows,defaultMCPLogsToolCount,effectiveMCPLogsToolTimeoutMinutes) cross-referenced against.github/workflows/deep-report.md's Step 2 prompt text (no scoping guidance present) and this cycle's live reproduction.