Bug Report: Supabase MCP list_tables Tool Causes Cursor IDE Termination Due to Excessive Output

[itaki]

Bug Report

Describe the bug

The Supabase MCP server's list_tables tool generates an excessive amount of data (approximately 3MB of JSON output) which causes Cursor IDE to stop functioning due to conversation length limitations. When attempting to use the list_tables tool through the MCP server, the conversation consistently becomes too long, causing Cursor to stop responding and requiring a new conversation to be started.

To Reproduce

Steps to reproduce the behavior:

1. Open Cursor IDE
2. Start a new conversation
3. Connect to Supabase using MCP tools
4. Successfully query database status (returns healthy)
5. Attempt to use the list_tables tool
6. Wait 10-15 seconds while Cursor processes
7. Conversation terminates with "conversation has gotten too long" error

https://imgur.com/a/9fvO8TZ

Returned Output

I only have this one database setup to test it on, but the issue is 100% reproducible, occurring every time the list_tables command is attempted. It has two main tables but also uses TimeScaleDB hypertables.

- NOTE: Claude thinks it's related to TimeScaleDB hypertables and their chunks.

Expected behavior

The list_tables tool should return the table list in a more concise format that doesn't exceed Cursor's conversation length limitations, allowing for continued interaction within the same conversation.

System information

• OS: macOS 24.1.0
• Cursor IDE Version: 0.48.9 (latest)
• Supabase MCP Version: 0.3.5
• PostgreSQL Engine Version: 15
• Specific PostgreSQL Version: 15.8.1.054
• Release Channel: GA (General Availability)

Additional context

• The tool generates approximately 3MB of JSON output data
• The output is extremely verbose and difficult to parse
• The issue occurs consistently in fresh conversations, indicating it's not related to previous conversation context
• Database health checks work fine before the list_tables attempt
• The conversation termination occurs after 10-15 seconds of processing time

Technical Details

The excessive output appears to be related to how the list_tables tool formats and returns the database schema information. The current implementation seems to include more verbose JSON formatting than necessary for basic table listing functionality. This may be related to TimeScaleDB hypertables and their chunks.

Active Extensions:

• pg_stat_statements (for query performance monitoring)
• pgcrypto (for cryptographic functions)
• pgjwt (for JWT handling)
• http and pg_net (for async networking)
• plv8 (for JavaScript procedures)
• uuid-ossp (for UUID generation)

[dennisdpj]

I have this problem as well. I don't see (and I've done some investigation, not an extreme amount) the option to easily get the schema for a table - Cursor always tries to work with list_tables and after 2 iterations the chat is too long..

[itaki]

Cursor always tries to work with list_tables and after 2 iterations the chat is too long..

I created a rule that specifies that Cursor is not allowed to use the list tables Supabase MCP tool, and it seems to work pretty well. I just gave it access to the Postgres MCP tool, so it switches to that when it needs to.

[dennisdpj]

Cursor always tries to work with list_tables and after 2 iterations the chat is too long..

I created a rule that specifies that Cursor is not allowed to use the list tables Supabase MCP tool, and it seems to work pretty well. I just gave it access to the Postgres MCP tool, so it switches to that when it needs to.

Thanks for the comment! That would work as well in my situation I guess - but it feels more as a dirty workaround than as a long-term fix.

[gregnr]

Thanks for reporting this @itaki. A few things that we're working on to address this:

1. Only pull tables from the public schema by default (instead of all schemas). The LLM will still be able to choose other schemas if it wants.
2. Remove list_tables and list_extensions and switch to a single tool that can query any metadata it wants in a terse format (tables, views, triggers, policies, functions, extensions, etc)

I agree the output today is bigger than it needs to be. Even so, 3MB seems excessive. Are you able to look at the list_tables response to see what kind of data is coming back? Can you tell if much of it relates to TimeScale hypertables? If you could share some or all of that JSON response that would also be helpful.

[itaki]

@gregnr Feel free to grab the output that I posted in my original post. I'm not really sure how to read it, but maybe it will make sense to you. Let me know if you need anything else.

[gregnr]

Thanks @itaki - I missed that earlier. I've confirmed that the vast majority of this JSON is from the internal tables timescaledb uses for their hypertables. I've created a PR to exclude these from the tool call: #65.

In the mean time you can ask the LLM to filter to a specific schema (or schemas) like public.