Add info-level logging to all MCP tools

[RafaelPo]

Summary

• Add info-level logging to all MCP tools that previously only logged on error
• Add happy-path logging to upload proxy (upload_id, size, artifact_id)
• Every tool now logs on entry (with key params) and on success (with outcomes)

Tools that gained logging:

Tool	Entry log	Success log
everyrow_browse_lists	search, category	result count
everyrow_use_list	artifact_id	artifact_id, rows
everyrow_progress	task_id	-
everyrow_results	task_id, offset, page_size	-
everyrow_list_sessions	offset, limit	-
everyrow_balance	-	balance amount
everyrow_cancel	task_id	-
upload request	upload_id, filename	-
upload proxy	upload_id, size	status, artifact_id

Test plan

• All 401 tests pass
• Ruff + pyright clean
• Deploy to staging and verify logs appear in Cloud Logging

🤖 Generated with Claude Code

[RafaelPo]

@claude code review

[github-actions]

Claude finished @RafaelPo's task in 48s —— View job

---

Code Review: Add info-level logging to all MCP tools

• Read changed files and gather context
• Review tools.py changes
• Review uploads.py changes
• Post review summary

---

Verdict: Looks good — clean, consistent, and useful for observability. A few minor notes below.

tools.py

The new log lines follow the existing pattern (tool_name: key=value) established by the pre-existing tools (e.g. everyrow_rank, everyrow_single_agent). Good consistency.

1. everyrow_progress uses debug while all others use info (line 1007) — this is intentional per the commit message ("Use debug-level logging for progress polling, info only on terminal"), and makes sense to avoid log spam from frequent polling. The terminal-state info log at line 1049 is a nice touch.

2. everyrow_balance logs the dollar amount (line 1297: logger.info("everyrow_balance: $%.2f", ...)). This is borderline — balance info isn't a secret per se, but it is business-sensitive data showing up in structured logs. Worth considering whether this should be debug level instead, or if you're comfortable with it at info given your log access controls. Not a blocker.

3. No entry log for everyrow_balance — the "called" log at line 1281 is fine, but it's the only tool that doesn't log any parameters on entry (since it takes none). Just noting for completeness; this is correct.

uploads.py

4. Good refactor: extracting upload_id = data["upload_id"] to a local variable (line 122) before using it in both the result dict and the log line. Clean.

5. resp.text[:200] in the warning log (line 240) — nice defensive truncation to avoid log bloat from large error bodies.

6. Bare except Exception: pass (lines 248-249) when parsing artifact_id from the response — this is pragmatic since the log is purely informational. If the response isn't JSON or lacks the key, artifact_id stays None and the log still works. Acceptable for a non-critical logging path.

Overall

No bugs, no security issues, no behavioral changes. The logging is consistent with the existing patterns in the codebase and will meaningfully improve observability in production. LGTM.

---