Supabase already did the hard part

When you create a table in Supabase, you immediately get a full REST API for it. List rows, create records, filter by column, update by ID, delete — all via standard HTTP endpoints, all backed by PostgREST under the hood.

That's a genuinely useful backend. But your AI agent can't talk to it yet.

The missing layer

AI agents — Claude, GPT-4, Gemini — interact with external systems through MCP servers. An MCP server describes a set of tools the agent can call, handles the HTTP requests, and returns the results. Without one, the agent has no way to query your database or update records.

You could build an MCP server yourself. But that means standing up infrastructure, managing authentication, and keeping tool definitions in sync with your schema. It's overhead that has nothing to do with the problem you're actually trying to solve.

Shredly bridges the gap

Shredly lets you define MCP tools that point directly at your Supabase REST endpoints, then hosts the server for you. No code, no infrastructure. You describe what the tool does and what parameters it accepts — Shredly handles the rest.

Here's what that looks like for a simple projects table:

{
  "name": "list_projects",
  "method": "GET",
  "url": "https://<project>.supabase.co/rest/v1/projects",
  "headers": { "Accept": "application/json" },
  "input_schema": {
    "status": {
      "type": "string",
      "description": "Filter by status. PostgREST format: eq.active or eq.archived.",
      "optional": true
    }
  },
  "response_transform": ".",
  "timeout_ms": 10000
}

When your agent calls list_projects, Shredly fires that GET request and returns the rows. If the agent passes a status filter, it's automatically appended as a query parameter — ?status=eq.active — exactly as PostgREST expects.

Authentication

Supabase authenticates requests via the apikey header. Shredly's ApiKey auth type with header: "apikey" forwards the caller's token on every outbound request — no manual header wiring per tool.

{
  "authentication": {
    "type": "ApiKey",
    "header": "apikey"
  }
}

When you connect your agent, you pass your Supabase service role key as a standard Bearer token. Shredly handles the conversion.

claude mcp add --transport http my-app-pm \
  https://mcp.shredly.io/mcp/my-app-pm \
  --header "Authorization: Bearer <your-service-role-key>"

Use your service role key for full access (bypasses Row Level Security), or your anon key if RLS policies should apply.

Targeting rows for PATCH and DELETE

PostgREST filters rows using query parameters in the form column=operator.value — for example, ?id=eq.abc-123. For mutations, you need that filter in the URL and the update data in the request body.

Shredly's :param URL templates make this clean. Embed the PostgREST operator prefix directly in the URL:

PATCH /rest/v1/projects?id=eq.:id

When the agent calls update_project with { "id": "abc-123", "status": "archived" }, Shredly resolves :id to produce ?id=eq.abc-123 in the URL, then sends the remaining fields — { "status": "archived" } — as the JSON body. The filter and the update payload go exactly where PostgREST expects them.

Getting the updated row back

By default, Supabase returns an empty 204 on POST and PATCH. That's not useful for an agent that needs to confirm what was created or changed. Add "Prefer": "return=representation" to those tool headers and PostgREST returns the full row instead.

The result

A single Shredly server can expose complete CRUD over every table in your Supabase project — list, create, update, delete — with proper filtering, row targeting, and authentication. Your agent can query data, create records, and update state, all without you writing a line of backend code.

If you're already using Supabase, you're most of the way there. Shredly closes the last mile.

See the Supabase guide in our docs for a complete server definition covering projects and tasks across two related tables.

Give Your AI Agent Full CRUD Access to a Supabase Backend