Cannot retrieve data from Supabase database — custom action and MCP both failing

Bugs / Site Issues
1

Pickaxe Support Ticket — June 3, 2026

Subject: Cannot retrieve data from Supabase database — custom action and MCP both failing

Apologies in advance for the length of this ticket. I want to give your team enough detail to troubleshoot without needing to go back and forth.

I’m not a technical person. I’ve been working through this with Claude AI as my assistant — using screenshots and prompts to navigate the process. Claude helped me document what we tried and what failed, which is why this ticket is detailed even though I couldn’t have written it on my own. I mention this so your team knows the context: responses that assume coding ability or deep technical knowledge won’t be easy for me to act on. Clear, step-by-step guidance would be most helpful.

What I’m trying to do

I’m building a Chief of Staff AI tool in Pickaxe. When a user opens a chat, I want the agent to look up their name in my Supabase database (using their email address) and greet them personally. Simple concept: user opens chat → agent queries Supabase → agent says “Good morning, Diana.”

I have a profiles table in Supabase with email and display_name columns. The data is there and correct. The query works perfectly when I run it from outside Pickaxe. The problem is getting it to work from inside a Pickaxe agent.

Approach 1 — Smithery Supabase MCPs

I first tried connecting Supabase via the Smithery MCP options available in the Actions library.

Result: All Smithery Supabase MCP variants failed immediately with the same error:

v3Schema.safeParseAsync is not a function

This happened on every Smithery Supabase variant I tried. I was not able to get any of them to work. I moved on.

Approach 2 — Custom Python Action (supabase_query)

I built a custom Python action that calls the Supabase REST API directly via HTTP. The code uses requests to call https://[project-id].supabase.co/rest/v1/profiles with the service role key in the headers and the user’s email as a filter.

The code works correctly when tested outside Pickaxe. Running the identical Python code from my own environment returns the correct user data every time.

Inside Pickaxe, the action fires but returns empty results. Here is what I observe in the Action runs tab:

  • Status: success
  • AI Filled Inputs: shows the correct parameters (operation: list, table: profiles, filter: ``email=eq.moveoutofmichigan@gmail.com, select: id,display_name, limit: 1)
  • Logs: No files found.

The action is being called with the right parameters, but returning empty — even though the same query against the same database returns data when run from outside Pickaxe.

My question: Can custom Python actions make outbound HTTP requests to external APIs like Supabase? Is there a network restriction in the Python sandbox that would cause HTTP calls to silently fail or return empty?

Approach 3 — Native Supabase MCP (node2flow)

I connected the native Supabase MCP available in the Pickaxe Actions library (server: https://supabase--node2flow.run.tools). It connected successfully and shows as active.

Problem: The MCP has no credentials configured (env: {}). I cannot find a way in the Pickaxe UI to provide it with my Supabase project URL and service role key. Without credentials, it cannot query my database.

My question: How do I configure the native Supabase MCP with my project credentials? Is there a UI for this, or does it need to be done another way?

The core question

I have user records in Supabase that I need agents to read and write during conversations. If I cannot reliably retrieve a simple name from the database, I cannot trust the system for more complex operations like writing session receipts, reading operating plans, and storing weekly reports — all of which are central to my use case.

If Supabase integration is not currently reliable in Pickaxe, I would appreciate:

  1. A recommended alternative database or storage service that works well with Pickaxe agents
  2. Or a clear path to making Supabase work — whether that’s a fix for the custom Python action networking, or instructions for configuring the native Supabase MCP with credentials

Environment details

  • Pickaxe agent ID: 5CIK00E4S5 (CoS - Daily Brief)
  • Supabase project ID: omjsqianefykbebnrdmp
  • The profiles table has id, email, display_name columns
  • The user email is passed via {PX_user_identifier} prompt variable
  • Model: Claude Sonnet

Thank you for your help.

2

hi @covetedconsultant !

i took a look and found a few things:

first off, thanks for the details, this was genuinely helpful.

also, for anyone else reading this and trying to do this kind of work alongside Claude/Codex/Cursor: the Pickaxe CLI can make this a lot easier. this seems to be what you were already doing, so 10 gold stars :sports_medal:

now for the good stuff: there was a small bug inside the custom Python action connected to this setup. the action had the right Supabase code, but the function we were calling was not actually returning the result from that code.

i made a small fix so the action entrypoint now delegates to the real Supabase query function:

def supabasequery(operation: str, table: str, filter: str, select: str, limit: str):
    return supabase_query(
        operation=operation,
        table=table,
        filter=filter,
        select=select,
        limit=limit,
    )

that should resolve the “action succeeds but returns empty” behavior. if you turned the custom action off while testing the MCP routes, just make sure it is enabled again on the agent.

i cloned the action, created a new Supabase DB, and tested it myself post-fix. it did successfully lookup my email and match it to my name in a profile collection!

image
image2314×1086 259 KB

two other important notes:

  1. the “when a user opens the chat” part

Pickaxe agents generally do their best work when a message is sent. so for a normal direct-link or embed experience, “open chat → immediately query Supabase → greet Diana” is not quite the default flow, per se.

the easier “Pickaxe-native” version is usually to use User Memory + a little bit of prompting so the agent can remember and reuse information about the user inside the conversation.

  1. {PX_user_identifier} depends on whether Pickaxe actually has a user identifier available

{PX_user_identifier} resolves to the user email when available, then user identifier if available, and Not Found if neither is available: Prompt Injectors | Pickaxe Docs

so: if you are using a direct link/embed and no email/user id is being passed into the session, then Supabase will receive that Not Found instead of the user’s email.

this is why above, you’ll see me explicitly say “lookup X email,” as this is a direct-link deployment!

the exact flow you described is still possible, it just usually belongs in an API deployment/custom app setup:

  • create an API deployment
  • your app knows the logged-in user’s email/id
  • your app sends that user id/email with the chat request
  • the agent uses that value to look up the matching Supabase profile
  • the first message can trigger the lookup and return “Good morning, Diana.”

so in a short version: your custom action had a small bug and that piece should now be fixed. re: the “auto-greet by user email on open” experience, i’d either use Pickaxe User Memory for the simpler path, or use an API deployment if you want full control over the app/user lookup flow!

if any of that was overly complicated or confusing, we highly highly recommend dropping by open office hours tomorrow at 11:00am PST. we’re always happy to help walk through this live: Pickaxe Office Hours · Luma

1 Like
3

Whew thanks! — just wanted to circle back and say thank you. Your fix to the supabasequery action (adding the missing return statement) was the unlock I needed.

What happened after your fix:

After the action started returning data correctly, I ran into a second issue: the agent was querying every downstream table with user_name=eq.alzay (my name) instead of the UUID we retrieved at session start. Our best guess is that the LLM was constructing that filter value from data it had seen in prior query results — user_name: alzay appeared in returned Supabase data and the agent started using it independently.

How I solved it:

Added a CRITICAL DATABASE RULES block at the very top of the main prompt that:

  • Explicitly forbids names as filter values
  • Requires the UUID from the initial profiles lookup for all downstream queries

That fixed it and queries are now consistently using the correct UUID.

Questions for you:

  1. Do you have any insight into why the agent would ignore a stored UUID and construct its own filter value from prior query results? I’m not 100% certain that’s the root cause.

  2. Is there a more reliable way to ensure the LLM uses a specific stored value as a filter — especially when that value needs to persist across a long session where multiple skill files [knowledge, base, queries, etc.] fire?

  3. My current pattern is: establish the UUID in the main prompt via CRITICAL RULES, then rely on skill files [specific linear instructions that are held in the knowledge base] to reference it for reads and writes (morning brief assembly, session receipt writes at close, etc.). Is this the right architecture for multi-table Supabase work across a full session?

    (by the way, I have a similar set up in my own personal Claude through MCPs. and things work pretty seamlessly. What I’m essentially trying to do is mimic a similar set up to give my clients. I’m using a chat, an “MCP” [started with Smithery, now I’m using the custom setup we described], and a database (Supabase) through Pickaxe)

Thanks again — this is hard! :slight_smile: