query_logs hint omits function_logs, so agents can't find Edge Function console output

[Rjabov]

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

On hosted projects get_logs is hidden (hidden: Boolean(queryLogs) in getDebuggingTools), so query_logs is the only logs tool in tools/list. Its ClickHouse schemaHint lists 'edge_logs', 'postgres_logs' and 'function_edge_logs' as the common sources, but not 'function_logs', which is where Edge Function console.log output actually goes.

The result: an agent asked "what did my edge function log?" reaches for function_edge_logs, gets the request envelope (status code, method, execution_time_ms), and reports it can't find the logs. The name similarity makes the wrong source look like the more specific choice.

The source clearly exists on ClickHouse: getClickHouseLogQuery already emits where source = 'function_logs' for the edge-function-runtime service. get_logs has a description that explains the split ("edge-function returns invocation/request logs, while edge-function-runtime returns console output from inside the function"), but that is the tool that gets hidden on hosted projects, so the agent never reads it.

To Reproduce

1. On a fresh hosted project, deploy an Edge Function that does console.log('smoke test') and invoke it once.
2. Connect an MCP client to @supabase/mcp-server-supabase@0.11.0 with --project-ref (hosted, ClickHouse dialect). tools/list exposes query_logs; its sql description does not mention function_logs.
3. Ask the agent, without naming any source: "what did my edge function log?"
4. The agent follows the hint to source = 'function_edge_logs' and gets only envelope rows (GET | 200 | https://.../functions/v1/smoke). The console output sitting in function_logs is never surfaced.

Reproduced today (2026-08-24) against a fresh free-tier project, both on the published 0.11.0 and on main at fc54ea2.

Expected behavior

The hint should name both Edge Function sources so the model can pick the right one: 'function_edge_logs' for invocation/request logs, and 'function_logs' for console output from inside the function.

Proposal: add the missing source to the ClickHouse schemaHint only. The BigQuery hint is correct as-is: self-hosted Logflare does not serve function_logs, and the existing not.toContain('function_logs') assertion in server.test.ts should stay untouched.

I have a fix ready (a one-line addition to the ClickHouse hint plus a test assertion) and will open a PR right after this issue.

System information

• @supabase/mcp-server-supabase 0.11.0 (also built from main at fc54ea2)
• Hosted project (ClickHouse logs dialect)

[mattrossman]

Hey @Rjabov, thanks for reporting this. We'll probably want to add an eval that demonstrates this failure case before making a fix, as well as update our MCP version pin there.

The tool currently mentions that its sample source list is "not exhaustive" and instructs clients to select distinct source from logs to discover available sources. Did your agent ever try to run that discovery step? In my initial testing with Claude Code / Sonnet 5, the agent correctly listed sources and found the correct one to read function console output.

If you can share the harness and model you used in testing, that'll allow us reproduce and track the failure scenario.

[Rjabov]

@mattrossman - followup with the harness details you asked for.

Setup: a CLI shim over tools/list + query_logs against a live project, fresh model
instance per run writing its own SQL, test function that returns 200 on every call while
logging an error line. 32 runs: 4 models × 2 prompts (a bare one, plus yours from
supabase/evals#232) × 2 reasoning levels × 2 builds.

Caveat first, because it matters for reading the numbers: this is a clean-room setup -
one function, a short window, single turn, no competing tools. In my day-to-day Opus use
this still fails regularly (it's improved recently, but it's nowhere near reliable). So
treat these pass rates as an optimistic floor, not as the real-world rate.

In the harness: Sonnet 6/8, Opus 7/7. Sonnet's two failures were both at low reasoning
effort - same model, same prompt, different budget.

#376 changes nothing. 14 directly comparable cells, zero flipped. Models already reach
function_logs unaided - Haiku queried it in 7/7 runs on both builds. The source was never
the broken step.

The column is. Haiku selected event_message in 0/7 runs. It reads log_attributes,
finds no message key, and tells the user "console.log output is not being stored in the
queryable project logs."

Adding event_message to the hint: the 5 previously-failing cells, 2 replicates each,
10/10 pass.

Given the same model flips on reasoning budget alone, a single Sonnet-5 eval run may be a
thin signal here. Happy to repoint #376 at event_message if that's useful.