Problem Description
The audit MCP tool accepts a max_tokens parameter, but it appears to have no effect on the size of the returned output.
Command/Tool
- Tool: audit
- Command:
printf '{"run_id":31566008792,"max_tokens":200}' | agenticworkflows audit .
Steps to Reproduce
- Run with no
max_tokens -> Tool output: 37604 chars
- Run with
max_tokens: 3000 -> Tool output: 37604 chars
- Run with
max_tokens: 200 -> Tool output: 37604 chars
All three produce an identically sized ~37.6KB JSON payload (confirmed via the bridge log line Tool output: 37604 chars), run against run_id: 31566008792 (a completed run of the "Daily GitHub Docs SEO Optimizer" workflow).
Expected Behavior
Setting a small max_tokens (e.g. 200 or 3000) should truncate/limit the returned audit report size, similar to how the logs tool honors max_tokens by writing full results to a cache file and returning only a small pointer message when the limit is exceeded.
Actual Behavior
The full, untruncated audit report is always returned regardless of the requested max_tokens value.
Environment
- Repository: github/gh-aw
- Run ID: 31567316674
- Date: 2026-08-12
Impact
- Severity: Low
- Frequency: Always (when using max_tokens with audit)
- Workaround: None found; callers must budget for the full report size regardless of requested limit.
Additional Context
Other areas of the exploratory test session behaved correctly: status (workflow discovery), logs (with count/max_tokens/date-range/engine/workflow_name filters, including edge cases like a nonexistent workflow name and a future start date — both returned clear, actionable messages), audit with a valid and an invalid run_id (clear error for invalid IDs), and compile with valid and nonexistent workflow names (clear resolution errors with suggestions). Performance was reasonable throughout (audit ~1s, compile ~0.1-1s, logs ~0.1-14s). No crashes, hangs, or other unexpected behavior observed.
Generated by 🧪 Daily Cli Tools Tester · auto · 42 AIC · ⌖ 4.05 AIC · ⊞ 13.5K · ◷
Problem Description
The
auditMCP tool accepts amax_tokensparameter, but it appears to have no effect on the size of the returned output.Command/Tool
printf '{"run_id":31566008792,"max_tokens":200}' | agenticworkflows audit .Steps to Reproduce
max_tokens-> Tool output: 37604 charsmax_tokens: 3000-> Tool output: 37604 charsmax_tokens: 200-> Tool output: 37604 charsAll three produce an identically sized ~37.6KB JSON payload (confirmed via the bridge log line
Tool output: 37604 chars), run againstrun_id: 31566008792(a completed run of the "Daily GitHub Docs SEO Optimizer" workflow).Expected Behavior
Setting a small
max_tokens(e.g. 200 or 3000) should truncate/limit the returned audit report size, similar to how thelogstool honorsmax_tokensby writing full results to a cache file and returning only a small pointer message when the limit is exceeded.Actual Behavior
The full, untruncated audit report is always returned regardless of the requested
max_tokensvalue.Environment
Impact
Additional Context
Other areas of the exploratory test session behaved correctly:
status(workflow discovery),logs(withcount/max_tokens/date-range/engine/workflow_namefilters, including edge cases like a nonexistent workflow name and a future start date — both returned clear, actionable messages),auditwith a valid and an invalidrun_id(clear error for invalid IDs), andcompilewith valid and nonexistent workflow names (clear resolution errors with suggestions). Performance was reasonable throughout (audit ~1s, compile ~0.1-1s, logs ~0.1-14s). No crashes, hangs, or other unexpected behavior observed.