Self-Hosted Supabase MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific Supabase domains like auth, database, storage, and migrations. However, some overlap exists between list_tables and list_extensions/list_migrations as they all list database entities, though their descriptions clarify the specific resources. The auth tools (create/update/delete/get/list_auth_user) are clearly differentiated by action.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, using snake_case uniformly. Examples include apply_migration, create_auth_user, execute_sql, list_tables, and update_auth_user. This predictability makes it easy for agents to understand and select tools.
Tool Count4/5
With 21 tools, the count is on the higher side but reasonable for a self-hosted Supabase server covering multiple domains like auth, database, storage, and migrations. It might feel slightly heavy, but each tool appears to serve a specific function without obvious redundancy.
Completeness4/5
The toolset provides comprehensive coverage for core Supabase operations, including CRUD for auth users, database queries, migrations, storage, and monitoring. Minor gaps exist, such as no direct tools for managing storage objects (only listing) or handling realtime subscriptions beyond listing publications, but agents can work around these using execute_sql or other tools.
Average 3.4/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It mentions connection methods but doesn't disclose permissions required, potential for data modification, rate limits, error handling, or that 'read_only' is a hint (not enforced). This is inadequate for a tool executing arbitrary SQL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and includes necessary technical context about connection methods without redundancy.
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?
Given the complexity of executing arbitrary SQL, no annotations, and no output schema, the description is incomplete. It should warn about security risks, explain the 'read_only' hint's limitations, and describe return formats or error cases to be minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning about parameters beyond implying SQL execution, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the verb 'executes' and the resource 'SQL query against the database', specifying it handles both direct connections and RPC fallbacks. However, it doesn't explicitly differentiate from sibling tools like 'apply_migration' or 'list_tables', which also interact with the database but for specific purposes.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, risks of arbitrary SQL execution, or when to prefer other tools like 'list_tables' for read-only operations or 'apply_migration' for schema changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is a list operation, implying read-only behavior, but doesn't cover critical aspects like authentication requirements, rate limits, pagination details (beyond implied by limit/offset), or error conditions. This leaves significant gaps for a tool accessing user data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently conveys the essential information without unnecessary elaboration, making it highly concise and well-structured.
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?
Given the lack of annotations and output schema, the description is incomplete for a tool that lists users from an authentication table. It misses details like return format (e.g., array of user objects), error handling, security implications, or how it interacts with sibling tools. For a data-access tool with no structured support, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('limit' and 'offset') well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as default behaviors or constraints, so it meets the baseline for high schema coverage without compensating value.
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 clearly states the action ('Lists') and resource ('users from the auth.users table'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_auth_user' (which likely retrieves a single user), but the plural 'users' implies a listing operation versus retrieval of a specific user.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_auth_user' for single-user retrieval or 'list_tables' for broader table listings, nor does it specify prerequisites such as authentication or database access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering by prefix but fails to describe critical behaviors like pagination mechanics (implied by limit/offset), authentication requirements, rate limits, error conditions, or what the output looks like. For a list operation with 4 parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Lists objects within a specific storage bucket') and adds a useful qualifier ('optionally filtering by prefix'). There is no wasted verbiage or redundancy, making it highly concise and well-structured.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the return format (e.g., list of objects with metadata), pagination behavior, error handling, or authentication needs. For a tool with 4 parameters and no structured output documentation, this leaves significant gaps for an agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all parameters. The description adds minimal value by mentioning prefix filtering but doesn't provide additional context beyond what's in the schema (e.g., examples of prefix usage, interaction between limit/offset). This meets the baseline for high schema coverage.
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 clearly states the verb ('Lists') and resource ('objects within a specific storage bucket'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_storage_buckets' or 'list_tables', which would require a more specific scope statement to earn a 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions optional filtering by prefix but doesn't address scenarios like when to use 'list_storage_buckets' instead or prerequisites for accessing buckets. This lack of contextual direction leaves the agent without usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it retrieves information (implying read-only), but doesn't specify permissions needed, rate limits, or what 'active' means (e.g., time thresholds). This leaves significant gaps for a tool that accesses system-level data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes the specific source ('pg_stat_activity'), making it highly concise and well-structured.
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?
Given the complexity of accessing database connections (a system-level operation) with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned (e.g., connection details, query states), security implications, or how to interpret results, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the input structure. The description doesn't need to add parameter details, and it correctly implies no inputs are required, earning a baseline high score for this context.
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 clearly states the verb ('retrieves') and resource ('information about active database connections from pg_stat_activity'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_database_stats' or 'list_tables', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_database_stats' or 'execute_sql'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a key 'if available,' which adds some context about potential failure modes, but doesn't cover other critical aspects like authentication requirements, rate limits, error handling, or what the return value looks like (e.g., format, structure). For a tool that handles sensitive data (service role key), this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core functionality ('Returns the configured Supabase service role key') and a key condition ('if available'). It is front-loaded with the main action and avoids any redundant or verbose language, making it highly concise and easy to parse.
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?
Given the tool's complexity (handling a sensitive service role key), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain the return format, error conditions beyond availability, security implications, or how this tool differs from siblings like 'get_anon_key.' For a tool in this context, more detail is needed to ensure safe and correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). In such cases, the baseline score is 4, as there are no parameters to document. The description doesn't need to compensate for any parameter gaps, and it appropriately focuses on the tool's purpose without unnecessary parameter details.
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 clearly states the tool's purpose with a specific verb ('Returns') and resource ('configured Supabase service role key'), making it immediately understandable. It distinguishes itself from siblings like 'get_anon_key' by specifying the service role key, though it doesn't explicitly contrast with all similar tools. The purpose is not vague or tautological, but could be slightly more specific about what 'this server' refers to.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_anon_key' or other sibling tools. It mentions 'if available,' which hints at a condition, but doesn't explain when the key might be unavailable or what to do in such cases. There are no explicit when/when-not instructions or named alternatives, leaving usage context largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information on output format (e.g., list structure, fields returned), pagination, error conditions, or whether it requires specific permissions. This leaves significant gaps for an agent to understand the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and efficient. Every word earns its place by specifying the exact scope ('all installed PostgreSQL extensions').
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?
Given the tool's simplicity (0 parameters) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., array of extension names with versions), which is critical for a list operation. For a read-only tool with no structured output documentation, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description appropriately doesn't discuss parameters since none exist. It could theoretically mention that no inputs are required, but this is adequately covered by the schema, so a baseline 4 is appropriate.
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 clearly states the verb ('Lists') and resource ('all installed PostgreSQL extensions in the database'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_tables' or 'list_auth_users', but the specificity of 'PostgreSQL extensions' provides inherent distinction.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., database connection), use cases (e.g., checking available extensions before installation), or how it differs from other list tools like 'list_tables' or 'list_auth_users'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'Lists applied database migrations,' implying a read-only operation, but doesn't disclose behavioral traits like permissions needed, rate limits, output format (e.g., list of migration IDs/timestamps), or pagination. For a tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Lists applied database migrations') and adds specific detail ('recorded in supabase_migrations.schema_migrations table'). Every word earns its place with no redundancy or fluff.
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?
Given no annotations, no output schema, and zero parameters, the description is minimal. It states what the tool does but lacks context on behavior, output, or usage. For a tool that likely returns structured migration data, this leaves the agent guessing about results and applicability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though trivial here). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No extra value is required beyond stating the purpose.
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 clearly states the verb ('Lists') and resource ('applied database migrations'), specifying the exact table ('supabase_migrations.schema_migrations'). It distinguishes from siblings like 'list_tables' or 'list_extensions' by focusing on migrations. However, it doesn't explicitly differentiate from hypothetical similar tools (e.g., 'list_pending_migrations'), so it's not a perfect 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after applying migrations), exclusions (e.g., not for pending migrations), or related tools like 'apply_migration'. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a list operation, implying read-only behavior, but doesn't disclose any behavioral traits like pagination, rate limits, authentication requirements, or what specific publication data is returned. For a tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and adds only relevant context about Supabase Realtime. Every word earns its place, making it appropriately sized.
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?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the list returns (e.g., publication names, details, format) or any behavioral aspects. For a list operation in a complex environment with many siblings, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it correctly doesn't mention any. Baseline for 0 parameters is 4, as it avoids unnecessary details.
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 clearly states the verb ('Lists') and resource ('PostgreSQL publications'), providing a specific purpose. It also adds context about Supabase Realtime usage, which is helpful. However, it doesn't explicitly distinguish this tool from sibling tools like 'list_tables' or 'list_extensions', which would require a 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions Supabase Realtime context, but doesn't specify scenarios, prerequisites, or exclusions. With many sibling tools available, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns real-time or cached data, or any error conditions. For a tool with zero annotation coverage, this leaves key behavioral traits unclear, scoring a 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and data sources. It's front-loaded with the core action ('Retrieves statistics') and avoids any unnecessary words, making it highly concise and well-structured, earning a 5.
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?
Given the tool's complexity (simple read operation with no parameters), no annotations, and no output schema, the description is minimally complete. It explains what the tool does but lacks details on return values, behavioral traits, or usage context. For a tool with no structured support, it's adequate but has clear gaps, scoring a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter details, so it meets the baseline of 4 for tools with no parameters. It appropriately focuses on the tool's purpose without redundant parameter explanations.
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 clearly states the tool's purpose: 'Retrieves statistics about database activity and the background writer' with specific sources (pg_stat_database and pg_stat_bgwriter). It distinguishes itself from siblings like get_database_connections (which focuses on connections) and list_tables (which lists tables), but doesn't explicitly contrast with all siblings. The verb 'retrieves' and resources 'statistics' are specific, earning a 4.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or compare with siblings like get_database_connections for connection stats or execute_sql for custom queries. Without any usage context, this is a significant gap, scoring a 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Lists') but doesn't describe how the listing works—e.g., whether it returns all buckets at once, uses pagination, requires specific permissions, or has rate limits. For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any wasted words. It is front-loaded and efficiently conveys the essential information, making it easy for an agent to parse and understand quickly.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It tells what the tool does but lacks details on behavior, output format, or usage context. For a list operation, more information on return values or constraints would be helpful, but the low complexity keeps it from being severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is given as it correctly avoids redundancy, though it doesn't compensate for any gaps (none exist).
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 clearly states the verb ('Lists') and resource ('all storage buckets in the project'), making the tool's function immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_storage_objects' or 'list_tables', but the specificity of 'storage buckets' provides adequate distinction. The purpose is unambiguous though not maximally differentiated.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_storage_objects' (which might list objects within buckets) or 'get_database_connections' (which might relate to storage), nor does it specify prerequisites or contexts for use. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions grouping by schema, which is helpful, but doesn't cover important aspects like pagination, rate limits, authentication requirements, error conditions, or what 'accessible' means in practice. For a tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. Every word earns its place—'Lists' (action), 'all accessible tables' (scope), 'in the connected database' (context), and 'grouped by schema' (organizational detail). No wasted words or redundancy.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but doesn't provide enough behavioral context (like how results are structured or what 'accessible' entails). For a read-only listing tool, it meets minimum viability but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately focuses on what the tool does rather than inputs. A baseline of 4 is appropriate for zero-parameter tools.
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 clearly states the verb ('Lists') and resource ('all accessible tables in the connected database'), and adds useful context about grouping by schema. It doesn't explicitly distinguish from siblings like 'list_extensions' or 'list_migrations', but the resource specificity makes the purpose clear.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, timing considerations, or how it differs from other listing tools like 'list_extensions' or 'list_migrations' in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'checks' and 'returns a preview,' implying a read-only operation, but doesn't specify details like what 'preview' entails (e.g., format, content), whether it requires authentication, or potential error conditions. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word contributes to understanding the tool's function without redundancy or unnecessary elaboration. It's appropriately sized for a simple, parameter-less tool.
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?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavior, output format, or usage context. For a simple check tool, this might suffice, but the absence of output schema means the description should ideally clarify what 'returns a preview' means, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is applied since the schema fully covers the lack of parameters, and the description doesn't introduce confusion.
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 clearly states the tool's purpose: 'Checks if the Supabase JWT secret is configured for this server and returns a preview.' It specifies the verb ('Checks'), resource ('Supabase JWT secret'), and scope ('for this server'), which distinguishes it from siblings like get_anon_key or get_service_key that retrieve different credentials. However, it doesn't explicitly differentiate from all siblings, such as get_database_connections, which might also involve configuration checks.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., server setup), exclusions (e.g., when other tools are more appropriate), or context for usage. Given the sibling tools include various configuration and management functions, this lack of guidance leaves the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Retrieves details') but doesn't describe what 'details' include, error handling (e.g., for invalid IDs), permissions required, or rate limits. For a read operation with zero annotation coverage, this leaves significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. Every word contributes meaning without redundancy, making it easy to parse quickly. It avoids unnecessary elaboration while covering the essential purpose.
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?
Given the tool's simplicity (one parameter, read-only operation) and high schema coverage, the description is adequate for basic use. However, without annotations or an output schema, it lacks details on return values, error cases, and security context. It meets minimum viability but has clear gaps in behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'user_id' fully documented in the schema as a UUID. The description adds minimal value beyond the schema by reiterating 'by their ID', but doesn't provide additional context like ID format examples or sourcing guidance. Baseline 3 is appropriate since the schema does the heavy lifting.
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 clearly states the verb ('Retrieves') and resource ('details for a specific user from auth.users'), making the purpose unambiguous. It specifies the data source ('auth.users') and key identifier ('by their ID'), which helps distinguish it from generic user-fetching tools. However, it doesn't explicitly differentiate from sibling 'list_auth_users', which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'by their ID', suggesting this tool is for fetching a single known user rather than listing multiple users. However, it doesn't explicitly state when to use this versus 'list_auth_users' or mention prerequisites like authentication requirements. The guidance is functional but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Returns'), but does not specify if this requires authentication, involves rate limits, or details the return format. The description adds minimal context beyond the basic action, resulting in an average score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states what the tool does without any unnecessary words. It is front-loaded and efficiently conveys the essential information, making it highly concise and well-structured.
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?
Given the tool's simplicity (zero parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks details on behavioral aspects like authentication or return format, which could be helpful for an agent in a broader context. It meets the minimum viable standard without being comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%, so there is no need for parameter details in the description. The baseline for zero parameters is 4, as the description appropriately focuses on the tool's purpose without redundant parameter information.
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 clearly states the action ('Returns') and the resource ('configured Supabase project URL'), making the purpose evident. However, it does not explicitly differentiate this tool from sibling tools like 'get_anon_key' or 'get_service_key', which also retrieve configuration values, so it falls short of a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives, such as other 'get_' tools for different configuration values. It lacks context about prerequisites or typical use cases, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions transactional execution and recording, which is useful, but lacks critical details like whether this requires admin permissions, what happens on failure (e.g., rollback), if it's idempotent, or any rate limits. For a tool that modifies database schema, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core functionality without redundancy. It's front-loaded with the primary action and includes essential behavioral context (transactional execution and recording). Every word earns its place with no wasted text.
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?
Given the tool's complexity (applies SQL migrations with transactional safety) and lack of both annotations and output schema, the description is moderately complete. It covers the what and how but misses important context like error handling, permissions, and return values. For a mutation tool with no structured safety hints, it should provide more operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (version, name, sql). The description doesn't add any parameter-specific semantics beyond what's in the schema—it doesn't explain parameter relationships, formatting constraints, or usage examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('applies a SQL migration script') and resource ('records it in the supabase_migrations.schema_migrations table'), distinguishing it from sibling tools like 'execute_sql' (which doesn't record migrations) and 'list_migrations' (which only lists them). It precisely defines the tool's function with both execution and tracking components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'SQL migration script' and 'within a transaction', suggesting it's for database schema changes. However, it doesn't explicitly state when to use this versus alternatives like 'execute_sql' for non-migration SQL or 'list_migrations' for checking status. No explicit when-not-to-use guidance or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Returns'), but doesn't disclose behavioral traits like authentication requirements, rate limits, whether the key is sensitive data, or what format the key is returned in. The description is minimal and lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple, parameterless tool.
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?
Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is complete enough for basic understanding but inadequate for operational use. It doesn't address security implications (anon keys are typically public but should be handled carefully), return format, or error conditions that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Returns') and resource ('configured Supabase anon key for this server'), distinguishing it from sibling tools like get_service_key or get_project_url by specifying the exact type of key being retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need the anon key for this server), but doesn't explicitly state when to use this tool versus alternatives like get_service_key or when not to use it. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the prerequisite for the pg_net extension, which is useful behavioral context. However, it lacks details on potential side effects (e.g., downtime, errors), success criteria, or response format, leaving gaps in transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that efficiently convey the action and prerequisite without any wasted words. Every sentence earns its place by providing essential 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?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It covers the prerequisite but omits details on what 'restart' entails, potential outcomes, or error handling. This leaves the agent with insufficient guidance for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description does not add parameter-specific information, which is unnecessary here. A baseline of 4 is appropriate as it compensates for the lack of parameters by focusing on usage context.
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 clearly states the tool's purpose with a specific verb ('restart') and resource ('pg_net worker'), making it understandable. However, it does not explicitly differentiate from sibling tools like 'list_extensions' or 'execute_sql', which might involve similar system operations, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by stating the prerequisite that 'the pg_net extension to be installed and available.' This helps guide usage, but it does not specify when not to use it or name alternatives among siblings, such as other maintenance tools, which would be needed for a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds critical context: the 'WARNING: Password handling is insecure' highlights a security risk, and 'Requires service_role key and direct DB connection' specifies authentication and connection requirements. This goes beyond what the input schema provides, covering safety and operational constraints that are essential for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first ('Updates fields for a user in auth.users'), followed by critical warnings and requirements. Every sentence earns its place by adding essential information without redundancy. It's concise yet comprehensive for its length, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description does a good job of being complete enough. It covers the purpose, security warnings, and prerequisites, which are crucial for a mutation tool. However, it doesn't explain return values or error handling, and with no output schema, this leaves a minor gap. For a tool with significant behavioral implications, it's mostly adequate but could be slightly more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description doesn't add any additional meaning or context about the parameters beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
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 clearly states the verb ('Updates') and resource ('fields for a user in auth.users'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'create_auth_user' or 'delete_auth_user', but the 'update' action is distinct enough to imply difference. The description is specific about what gets updated (user fields) rather than being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with 'Requires service_role key and direct DB connection', which indicates prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like 'create_auth_user' or 'delete_auth_user', nor does it provide exclusions or comparisons. The guidance is implied rather than explicit, leaving some ambiguity about optimal use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context beyond basic functionality by mentioning the download action, platform return for path formatting, and prerequisites. However, it lacks details on error handling, rate limits, or what happens if the file already exists, which are important for a tool that writes files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first, followed by key behavioral details and prerequisites. Every sentence adds necessary information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (file generation with prerequisites) and no output schema, the description is mostly complete. It covers the purpose, key behavior, and prerequisites, but could improve by detailing the return value format or error scenarios. However, it adequately supports tool selection and invocation in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some value by implying the use of 'supabase gen types' and mentioning platform-specific path examples, but it does not provide additional semantic details beyond what the schema specifies, such as format constraints or interactions between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generates TypeScript types from the database schema') using the Supabase CLI, identifies the resource ('database schema'), and distinguishes it from sibling tools like 'execute_sql' or 'list_tables' by focusing on type generation rather than data manipulation or listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Generates TypeScript types from the database schema') and mentions prerequisites ('Requires DATABASE_URL configuration and Supabase CLI installed'), but it does not explicitly state when not to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: this is a write operation (implied by 'Creates'), it requires plain text passwords (security risk), and it operates directly on the auth.users system. The warning about insecurity adds important context beyond what the input schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly sized at two sentences with zero wasted words. The first sentence states the purpose clearly, and the second provides crucial warnings. Every sentence earns its place, and the structure is front-loaded with the core functionality followed by important caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no annotations and no output schema, the description does well by clearly stating it's a creation tool and providing critical security warnings. However, it doesn't mention what happens on success/failure, whether the operation is idempotent, or what permissions are required. Given the complexity of user creation and lack of output schema, some additional behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. However, it does reinforce the password security warning mentioned in the schema, providing marginal additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Creates a new user') and target resource ('directly in auth.users'), distinguishing it from sibling tools like 'update_auth_user' or 'get_auth_user'. It uses precise language that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Creates a new user') and includes a strong warning about security implications ('WARNING: Requires plain password, insecure. Use with extreme caution.'). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a destructive operation ('Deletes'), specifies authentication requirements ('Requires service_role key'), and indicates infrastructure needs ('direct DB connection'). It does not mention potential side effects (e.g., cascading deletions) or response format, but covers critical safety and access aspects adequately for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero wasted words: the first states the core action and target, and the second specifies prerequisites. It is front-loaded with the primary purpose and efficiently conveys essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with authentication requirements), no annotations, and no output schema, the description does well by covering purpose, prerequisites, and behavioral traits. It lacks details on return values or error handling, but for a single-parameter tool with high schema coverage, it provides sufficient context for safe invocation, though not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'user_id' fully documented in the schema as a UUID. The description adds no additional parameter semantics beyond implying the ID is used for deletion, which is already clear from the schema. This meets the baseline score of 3 when the schema provides complete parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Deletes'), target resource ('a user from auth.users'), and identifier mechanism ('by their ID'), distinguishing it from sibling tools like update_auth_user or list_auth_users. It provides a precise verb+resource combination that leaves no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states prerequisites ('Requires service_role key and direct DB connection'), which helps determine when this tool can be used. However, it does not specify when to use it versus alternatives (e.g., update_auth_user for deactivation vs. deletion) or provide exclusions, limiting its guidance to context setup rather than comparative decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![selfhosted-supabase-mcp MCP server](https://glama.ai/mcp/servers/HenkDz/selfhosted-supabase-mcp/badges/card.svg)](https://glama.ai/mcp/servers/HenkDz/selfhosted-supabase-mcp)

Score Badge

Copy to your README.md:

[![selfhosted-supabase-mcp MCP server](https://glama.ai/mcp/servers/HenkDz/selfhosted-supabase-mcp/badges/score.svg)](https://glama.ai/mcp/servers/HenkDz/selfhosted-supabase-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HenkDz/selfhosted-supabase-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server