This server provides tools to manage Supabase Storage buckets and files, focusing on additive-only operations — no deletion or overwriting is permitted.
List buckets — View all existing buckets with their public/private status, file size limits, and allowed file types.
Create a bucket — Create new storage buckets with configurable privacy, allowed MIME types, and file size limits.
Upload a file — Upload a local file to a bucket with pre-upload validation of file type and size; never overwrites existing files.
List files — Browse files in a bucket or specific folder, with file sizes and last-updated dates.
Get a signed (temporary) URL — Generate a temporary shareable link for files in private buckets, valid for 1–30 days (default 7).
Get a public URL — Retrieve a permanent public web link for files in public buckets.
Move or rename a file — Move or rename a file within or across buckets; never overwrites an existing file at the destination.
Copy a file — Copy a file within a bucket or to another bucket, keeping the original in place; never overwrites existing files.
⚠️ No destructive operations (delete, overwrite, empty) are available.
Provides tools for managing Supabase storage buckets and files, including creating buckets, uploading files, listing files, generating signed URLs, and moving files.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Supabase Storage MCP Server Create a new bucket for the Q3 launch."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Claude Code plugin that lets you create storage buckets and upload media (images, video, audio, PDFs, design assets) to Supabase — just by chatting with Claude. It fills the gap left by the official Supabase MCP, which has no Storage bucket API.
Storage-only and additive-only by design:
🚫 No delete anything. There is no tool to delete, remove, or empty a bucket or file.
🚫 No overwrite. Uploads and moves never replace an existing file — a name clash fails cleanly.
🚫 No database access. The plugin exposes storage tools only; it cannot read or change your data.
Were you handed this folder to use, not to set up? Open START-HERE.md — a 3-minute, plain-language guide. The rest of this README is for whoever installs and configures it.
Node.js 18 or newer (node --version).
Access to your Supabase project in the Supabase dashboard.
In the Supabase dashboard, open the project, then:
Project URL — Project Settings → Data API → Project URL
(looks like https://abcdefghijklmno.supabase.co).
Service role key — Project Settings → API Keys → reveal the service_role key.
⚠️ The service role key is sensitive — treat it like a password. It can access the whole project, so never commit it, paste it in chat, or share it. This plugin only ever uses it for Storage operations and exposes no database tools, but the key itself is still powerful. Keep it in the
.envfile (which is gitignored) and nowhere else.
Copy the template to a real env file, in the plugin folder:
cp .env.example .envOpen .env and paste your two values:
SUPABASE_URL=https://<your-project-ref>.supabase.co
SUPABASE_SERVICE_ROLE_KEY=<your-service-role-key>The plugin ships with a prebuilt dist/, so if you just cloned it you can usually skip straight to
installing it in Claude. If you edited the source (or want to be sure), run:
npm install # installs dependencies and builds dist/ automatically
npm test # optional: runs the guardrail tests (should print "pass 10")Add this folder as a plugin (via your Claude Code plugin marketplace/config). The plugin's
.claude-plugin/plugin.json registers a local stdio MCP server that runs dist/index.js. Once
installed, Claude will have eight supabase-storage tools and the /upload-media guide available.
To verify quickly from a terminal, you can start the server directly — it should print
supabase-storage MCP server ready:
npm startTool | What it does |
| List buckets with their public/private, size limit, and allowed types |
| Create a bucket (naming convention enforced; defaults to private, 50MB, common media) |
| Upload a local file (validates type + size first; never overwrites) |
| List files in a bucket (optionally in a folder), with sizes and dates |
| Make a temporary shareable link (default 7 days) — works for private buckets |
| Get the permanent public link — for public buckets |
| Rename or move a file — within a bucket or into another bucket (never overwrites) |
| Copy a file — within a bucket or into another bucket — keeping the original (never overwrites) |
Enforced in code. A bucket name must start with an allowed category prefix, then lowercase words joined by dashes:
^(marketing|brand|campaigns|media|assets)(-[a-z0-9]+)+$Examples: marketing-q3-launch, brand-logos, campaigns-spring-2026, media-product-shots,
assets-social-templates.
To add or change the allowed prefixes, edit ALLOWED_BUCKET_PREFIXES in
src/config.ts and run npm run build.
Related MCP server: S3 MCP Server
You don't need to know any of the technical stuff. Just talk to Claude. Try the /upload-media
command, or say things like:
"What storage buckets do we have?" → Claude lists them.
"Make a new bucket for the Q3 launch." → Claude creates marketing-q3-launch (it'll ask if it
should be private or public).
"Upload C:\Users\me\Pictures\hero.png to the marketing-q3-launch bucket." → Claude uploads it and tells you where it landed.
"Give me a shareable link for hero.png." → Claude makes a link (a temporary one for private buckets, valid 7 days by default; a permanent one for public buckets).
"Rename hero.png to hero-final.png." → Claude moves it.
Good to know:
Nothing you do here can delete or overwrite a file. If a name is already taken, Claude will ask you to pick a different one. Explore freely.
Private vs public: private files are shared with a temporary link; public files (like logos) get a permanent web link. When in doubt, private is the safe default.
If something doesn't work, Claude will explain it in plain language — e.g. "that file type isn't allowed here" or "that bucket doesn't exist yet." If it mentions credentials or the network, that's a setup issue — tell whoever installed the plugin; it's not something you did wrong.
Run through this once with Claude to confirm everything works end to end:
Create a bucket — ask Claude to create media-test-bucket (private). ✅ It's created.
Upload an image — ask Claude to upload a small image to it. ✅ It returns the stored path and offers a signed link.
List files — ask Claude to list files in media-test-bucket. ✅ Your image appears with its
size and date.
Signed URL — ask for a shareable link to the image. ✅ You get a URL; opening it shows the image.
Duplicate upload fails — upload the same file to the same path again. ✅ It fails with "that name is already taken — choose a different name" (nothing is overwritten).
Bad bucket name fails — ask Claude to create a bucket called TestBucket or random-name.
✅ It's refused with an explanation of the naming rule.
If all six behave as described, the plugin is working.
TypeScript stdio MCP server using @modelcontextprotocol/sdk and @supabase/supabase-js.
Source in src/ (one file per tool under src/tools/), compiled to dist/.
Guardrails live in code: naming regex and defaults in src/config.ts; client-side
validation in src/validation.ts; friendly error mapping in
src/errors.ts.
npm test runs guardrail tests, including a structural check that no destructive Storage call
(.remove, deleteBucket, emptyBucket) and no upsert: true exists anywhere in the build.
This is an interim, disposable tool and may be replaced by a more complete solution later.
Create a new Supabase Storage bucket. Bucket names must start with one of: marketing, brand, campaigns, media, assets, then use lowercase letters, numbers, and dashes (for example: "marketing-q3-launch" or "brand-logos"). By default the bucket is PRIVATE (files need a signed link to view), accepts common media (images, video, audio, PDF), and limits files to 50MB. Set public=true only for assets meant to be shared openly on the web. If the name breaks the convention or already exists, creation fails with a clear explanation — nothing is overwritten.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Bucket name. Must match the convention, e.g. "marketing-q3-launch" or "brand-logos". | |
| public | No | true = anyone with the URL can view files (for openly shared assets). false (default) = private; files need a signed link. | |
| allowed_mime_types | No | Optional list of allowed file types, e.g. ["image/*", "application/pdf"]. Defaults to common media types. | |
| file_size_limit_mb | No | Optional maximum file size in megabytes. Defaults to 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: default privacy, allowed MIME types, file size limit, naming rules, and failure handling (clear error, no overwrite). This gives the agent a complete behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the action, and every sentence adds useful information. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation behavior well but does not describe the return value (e.g., bucket ID) or any side effects beyond failure. Still, given no output schema and the context of sibling tools, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value beyond schema by explaining naming pattern, defaults, and appropriate use of public flag. It enriches understanding without repeating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new storage bucket. It distinguishes itself from siblings like upload_file or list_buckets by using specific verb 'create' and resource 'bucket'. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to set public=true and naming conventions. However, it does not explicitly contrast with sibling tools or state when not to use it, which would make it stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the permanent public web link for a file. This only works for PUBLIC buckets — files anyone can view. If the bucket is private, this explains that and points you to 'get_signed_url' for a temporary link instead. Use this for logos, campaign images, and other openly shared assets.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | Yes | The bucket the file is in (must be a public bucket). | |
| file_path | Yes | Path to the file inside the bucket, e.g. 'logo.png' or 'logos/logo.png'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses behavior for both public and private buckets, but doesn't specify exact return format (e.g., URL string). Still highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: statement, conditional, use case. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for the tool's purpose: explains behavior, parameter constraints, and offers guidance for edge case (private bucket). No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds extra context (e.g., example paths) but doesn't significantly enhance beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get the permanent public web link for a file') and distinguishes from sibling 'get_signed_url' by specifying it works only for public buckets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (public buckets, logos, campaign images) and when not to (private buckets), and points to the alternative 'get_signed_url'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a temporary shareable link to a file. This works for PRIVATE buckets: anyone with the link can view the file until it expires. The default link lasts 7 days; you can ask for anywhere from 1 to 30 days. Use this to share media that shouldn't be public forever.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | Yes | The bucket the file is in. | |
| file_path | Yes | Path to the file inside the bucket, e.g. 'logo.png' or 'logos/logo.png'. Use 'list_files' to find it. | |
| expires_in_days | No | How many days the link stays valid. Default 7, maximum 30. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: temporary link, expiry duration, default 7 days, range 1-30, and that anyone with the link can view. No annotations provided, so description carries full burden; still lacks details about revocability or link format, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff, front-loaded with action verb. Efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, parameter hints, and behavior. Lacks explicit mention of return value (signed URL), but for a simple tool this is minor. Could mention link expiry more prominently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions; the tool description adds context (use list_files to find file_path, default expiry). Schema coverage is 100%, and description enhances understanding beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates a temporary shareable link for files in private buckets, distinguishing it from siblings like get_public_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it works for private buckets and hints at when not to use (public buckets), though does not name specific alternatives like get_public_url directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Supabase Storage buckets with their settings: whether each is public or private, its file size limit, and which file types it accepts. Use this first when someone asks 'where can I upload this?' or before creating a new bucket, so you don't duplicate one that already exists.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It describes what information is returned but does not mention behavioral traits like pagination, error handling, or side effects. Adequate for a simple read operation but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the action and output, second provides usage guidance. Front-loaded and efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, read-only list), the description fully covers what it does and when to use it. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%, so baseline is 4. The description adds no parameter info, which is acceptable since none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'buckets', specifies the settings returned (public/private, file size limit, accepted file types), and implicitly distinguishes from sibling tools like create_bucket or get_public_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool first when someone asks 'where can I upload this?' or before creating a new bucket to avoid duplicates, providing clear when-to-use and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the files in a bucket, with their sizes and last-updated dates. Optionally pass a folder prefix (e.g. 'logos') to look inside a specific folder. Handy for checking what's already there before uploading, or finding the exact path to make a shareable link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional maximum number of files to return (default 100). | |
| bucket | Yes | The bucket to look in. Use 'list_buckets' to see options. | |
| folder | No | Optional folder to list inside, e.g. 'logos' or 'campaigns/spring'. Omit for the top level. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly indicates a read operation and optional folder prefix, but lacks details on pagination, sorting, error handling (e.g., bucket not found), or default limit behavior beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences covering purpose, optional parameter, and use cases. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes output content (sizes, dates) and common use cases. Lacks return format or error details, but acceptable given simplicity and no output schema requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds minimal extra meaning beyond schema, only mentioning 'folder prefix' as a use case rather than adding new semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List the files in a bucket' with specific output details (sizes, last-updated dates). Distinguishes from siblings like list_buckets and upload_file by focusing on file listing within a bucket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides two explicit use cases: checking before uploading and finding paths for shareable links. Does not mention when not to use this tool or compare with alternatives like get_public_url or get_signed_url.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move or rename a file within a bucket (for example, tidy 'draft.png' into 'logos/final.png'). This NEVER overwrites: if something already exists at the new path, the move fails and asks you to pick a different name. It moves the file, so the old path no longer holds it.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | Yes | The bucket the file lives in. | |
| to_path | Yes | New path/name for the file, e.g. 'logos/final.png'. Must not already exist. | |
| from_path | Yes | Current path of the file, e.g. 'draft.png' or 'logos/draft.png'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses non-overwrite behavior, failure condition, and that old path no longer holds the file. Missing details on permissions or limits, but acceptable for this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with front-loaded purpose and a useful example. Every sentence adds value; no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (3 params, no output schema), the description covers all necessary behavioral aspects: purpose, constraint, effect. Complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds an example and reinforces the no-overwrite constraint, but does not add substantial meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'move or rename' and resource 'file within a bucket'. Provides concrete example and distinguishes from siblings like upload_file, which creates/overwrites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the NEVER overwrites constraint and behavior when destination exists. Does not explicitly mention when not to use or alternative tools, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local file (image, video, audio, PDF, design asset) to a bucket. The file type and size are checked against the bucket's rules BEFORE uploading, so problems are caught early with a clear message. This NEVER overwrites: if a file with the same name already exists, the upload fails and asks for a different name. On success it returns the stored path, and for private buckets it reminds you to make a shareable link with 'get_signed_url'.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | Yes | The bucket to upload into. Use 'list_buckets' to see options. | |
| content_type | No | Optional MIME type override, e.g. 'image/png'. Normally auto-detected from the extension. | |
| local_file_path | Yes | Full path to the file on this computer, e.g. C:/Users/me/Pictures/logo.png | |
| destination_path | No | Where to store it inside the bucket. Omit to use the file's own name. End with '/' to place it in a folder, e.g. 'logos/' stores it as logos/<filename>. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses key behaviors: early validation of file type and size, no overwrite policy, return of stored path, and a reminder for signed URLs on private buckets. It does not cover authentication or rate limits, but covers the main mutation aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with the purpose, and each sentence adds essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of an output schema, the description covers key return information (stored path) and important edge cases (duplicate names, private buckets). It could mention more about error responses but is sufficient for common use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-described in the schema. The description adds overall context but does not significantly enhance per-parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads local files to a bucket and lists supported types. It does not explicitly differentiate from sibling tools like move_file or create_bucket, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit guidance by noting that duplicates are not overwritten and that for private buckets a signed URL should be used. However, it lacks explicit when-to-use or when-not-to-use comparisons with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0create_bucketget_public_urlget_signed_urllist_bucketslist_filesmove_fileupload_fileEach tool has a clearly distinct purpose: bucket creation, listing, file listing, uploading, moving, and generating public or signed URLs. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_bucket, list_files, move_file), making them predictable and easy to understand.
With 7 tools, the set is well-scoped for a storage server, covering essential operations without being overwhelming or too sparse.
The set covers core operations (create, list, upload, move, get URLs) but lacks deletion capabilities for both buckets and files, which are notable gaps for a storage service.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your Supabase account in natural language: run SQL, apply migrations, manage tables, storage, edge f
Upload, organize, search, and transform images, videos, and files with AI-powered tools.
File uploads for AI agents. Upload, list, and manage files. No signup required.
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/danizeap/Supabase-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
