Skip to main content
Glama

Supabase: Check function health

supabase_check_function_health
Read-only

Check whether a Supabase Edge Function responds correctly by verifying its health and detecting failures before they affect dependent workflows.

Instructions

[UNIFIED] Check if an Edge Function is responding correctly.

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>",
      "function_name": "<function_name>"
    },
    "name": "supabase_check_function_health"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYes
function_nameYes

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

C2.9/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, non-mutating probe, which lowers the disclosure bar. The description adds only 'responding correctly' as behavioral context, leaving undefined what counts as healthy (status code, timeout, body check) and whether authentication is required, so it adds little beyond annotations.

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 front-loaded sentence with no filler, but the '[UNIFIED]' prefix carries no discoverable meaning and the brevity is achieved by omission rather than compression.

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

Completeness2/5

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

For a tool with two required, fully undocumented parameters and no output schema, the description needs to explain inputs and what a 'healthy' result looks like. It does neither, so the agent cannot confidently construct a call or interpret the response.

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 neither 'site' nor 'function_name' is documented anywhere. The description implies 'Edge Function', which hints at function_name, but says nothing about the site parameter or accepted formats (project ref vs URL), leaving the caller to guess both values.

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+resource: checking whether an Edge Function is responding correctly. That distinguishes it from generic site-wide health checks in the sibling list, but it does not differentiate it from near-siblings like supabase_test_function or supabase_invoke_function, so it stops short of full 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 guidance on when to reach for this tool versus the alternatives, nor any prerequisites. The presence of an overlapping supabase_test_function and supabase_invoke_function makes that omission material rather than cosmetic.

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