Skip to main content
Glama

Supabase: Get table relationships

supabase_get_table_relationships
Read-only

Retrieve foreign key relationships for a Supabase table, including both inbound and outbound references, to map how tables connect before writing queries or migrations.

Instructions

[UNIFIED] Get foreign key relationships for a table (both references to and from this table).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>",
      "table": "<table>"
    },
    "name": "supabase_get_table_relationships"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYes
tableYes
schemaNopublic

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0
  2. Removedv3.13.1
  3. First observedv3.4.0

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

readOnlyHint=true already tells the agent this is a safe read, so the description's job is lighter. It adds genuinely useful behavioral context by stating results include both inbound and outbound foreign keys, but says nothing about what happens for a nonexistent table, result depth/format, or whether cross-schema references appear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single well-formed sentence that front-loads the action and the resource. The only wasted element is the unexplained "[UNIFIED]" tag, which consumes attention without conveying actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a small read-only lookup with no output schema, the core behavior is conveyed, but three parameters are entirely undocumented and the shape of the returned relationship data (columns, direction indicator, referenced schema/table) is left implicit. Adequate but with clear gaps an agent would hit on first invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the parameter burden and does not: it never explains what "site" refers to, that "table" is the target table name, or that "schema" defaults to "public" and controls namespace resolution. Only an implied link between "for a table" and the table parameter exists.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("Get foreign key relationships") and clarifies scope with "both references to and from this table," which is meaningfully more precise than the title. It does not explicitly distinguish itself from the close sibling supabase_get_table_constraints, which likely also surfaces foreign keys, and the unexplained "[UNIFIED]" prefix adds noise rather than clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of prerequisites (e.g., needing a schema or permissions), and no routing to or away from alternatives like supabase_get_table_constraints or supabase_get_table_schema. The bidirectional scope note describes output, not usage conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools