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
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions within the Supabase ecosystem. For example, auth operations (create_auth_user, get_auth_user, update_auth_user, delete_auth_user, list_auth_users) are clearly separated from storage operations (list_storage_buckets, list_storage_objects), database operations (execute_sql, list_tables, list_extensions), and monitoring tools (get_database_stats, get_database_connections). No tools appear to overlap in functionality.
Naming Consistency5/5
The tool names follow a highly consistent verb_noun pattern throughout, with clear action prefixes like 'get_', 'list_', 'create_', 'update_', 'delete_', 'apply_', 'execute_', 'generate_', and 'verify_'. All tools use snake_case consistently, making them predictable and readable. Examples include get_anon_key, list_auth_users, apply_migration, and verify_jwt_secret.
Tool Count4/5
With 21 tools, the count is slightly high but reasonable for a comprehensive Supabase management server covering authentication, database operations, storage, monitoring, and migrations. The tools are well-scoped across different domains rather than being redundant. A minor reduction could improve focus, but the count aligns with the server's broad purpose.
Completeness5/5
The tool set provides complete coverage for managing a self-hosted Supabase instance, including CRUD operations for auth users, database querying and monitoring, storage bucket and object listing, migration management, and utility functions like generating TypeScript types and verifying configurations. No obvious gaps exist; agents can perform all essential administrative and development tasks without dead ends.
Average 3.5/5 across 21 of 21 tools scored. Lowest: 2.9/5.
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 the full burden of behavioral disclosure. It states it 'retrieves details' but doesn't specify what details are included, whether it's a read-only operation, error handling for invalid IDs, or any rate limits. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
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 without unnecessary words. It is front-loaded with the core action and resource, making it easy to understand quickly. Every part of the sentence contributes essential information.
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 user retrieval (which may involve authentication, data sensitivity, or error cases), the description is insufficient. With no annotations and no output schema, it fails to explain what details are returned, potential errors, or security considerations. This makes it incomplete for effective agent use.
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 description mentions retrieving by 'ID', which aligns with the 'user_id' parameter in the schema. Since schema description coverage is 100%, the schema already fully documents the parameter, so the description adds minimal value beyond confirming the parameter's role. 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 action ('Retrieves details') and resource ('specific user from auth.users'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_auth_users' or 'get_database_connections', which would require explicit comparison to achieve a score of 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 like 'list_auth_users' for multiple users or other user-related tools. It lacks context about prerequisites, such as needing a specific user ID, and doesn't mention any exclusions or typical use cases.
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's a list operation, implying read-only behavior, but doesn't cover critical aspects like authentication requirements, rate limits, error conditions, or the format of returned data. This leaves significant gaps for a tool that interacts with authentication 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 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.
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 insufficient for a tool that lists authentication users. It doesn't explain what data is returned (e.g., user fields, pagination metadata), security implications, or error handling, which are critical for an agent to use this tool effectively in a real-world 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?
The schema description coverage is 100%, with both parameters ('limit' and 'offset') well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline for adequate but not enhanced parameter semantics.
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 distinguishes itself from siblings like 'get_auth_user' (singular retrieval) and 'create_auth_user' (creation), though it doesn't explicitly mention pagination or filtering capabilities that might differentiate it further from other list tools.
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. It doesn't mention scenarios like bulk user retrieval, pagination needs, or comparisons with other list tools (e.g., 'list_tables'), leaving the agent to infer usage based on the name and schema 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 optional filtering but doesn't describe important behavioral aspects like pagination behavior (implied by limit/offset but not explained), authentication requirements, rate limits, error conditions, or what the output looks like. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves.
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 concise at a single sentence that communicates the core functionality. It's front-loaded with the main purpose and includes the optional filtering capability without unnecessary elaboration. Every word serves a purpose, making it efficient 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.
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 (4 parameters, no output schema, no annotations), the description is insufficiently complete. It doesn't explain what the output contains (object metadata, URLs, sizes), how pagination works with limit/offset, error handling, or authentication requirements. For a storage listing tool that likely returns structured data, the description should provide more context about the expected results and operational constraints.
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 description adds minimal value beyond the input schema, which has 100% coverage. It mentions 'optionally filtering by prefix' which corresponds to the 'prefix' parameter already documented in the schema. The schema already provides clear descriptions for all parameters including bucket_id, limit, offset, and prefix with examples. The description doesn't add any additional context about parameter interactions or usage patterns.
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 objects') and resource ('within a specific storage bucket'), making the purpose immediately understandable. It distinguishes from sibling tools like 'list_storage_buckets' by focusing on objects within buckets rather than the buckets themselves. However, it doesn't explicitly contrast with other listing tools like 'list_tables' or 'list_auth_users', which would require more specific differentiation.
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 explain when this filtering is appropriate or compare it to other tools for similar tasks. With multiple sibling listing tools available, the lack of contextual guidance leaves the agent to infer usage scenarios independently.
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 action ('Retrieves') but doesn't cover critical aspects like whether this is a read-only operation, potential performance impacts, authentication requirements, or rate limits. This leaves significant gaps for a tool that likely 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 that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of database monitoring and the lack of annotations and output schema, the description is insufficient. It doesn't explain what information is retrieved (e.g., connection details, query status), the format of the output, or any behavioral constraints, leaving the agent with incomplete context for safe and effective use.
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% coverage (though empty). The description doesn't need to explain parameters, so it meets the baseline of 4 for parameterless tools by not introducing confusion or redundancy.
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 siblings 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 such as 'get_database_stats' or 'execute_sql'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on 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 full burden for behavioral disclosure. It states the tool lists publications but doesn't describe what format the output takes, whether it's paginated, if it requires specific permissions, or any rate limits. For a tool with zero annotation coverage, this is insufficient behavioral 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 perfectly concise at one sentence with zero wasted words. It front-loads the core purpose ('Lists PostgreSQL publications') and adds only relevant supplemental context. Every word earns its place in this efficient description.
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 proper tool usage. While it states what the tool does, it doesn't explain what the output looks like, any behavioral constraints, or how results are structured. For a listing tool in a database context, more completeness 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 zero parameters with 100% schema coverage, so the schema already fully documents the empty parameter set. The description appropriately doesn't waste space discussing nonexistent parameters, earning a baseline score above minimum viable. It could mention that no filtering parameters are available, but this isn't required.
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 as 'Lists PostgreSQL publications' with the specific resource identified. It adds context about Supabase Realtime usage, which helps distinguish it from generic database listing tools. However, it doesn't explicitly differentiate from sibling tools like list_tables or list_extensions, keeping it from 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. While it mentions Supabase Realtime context, it doesn't specify prerequisites, timing considerations, or comparisons with other listing tools in the sibling set. This leaves the agent without usage direction.
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. While 'Lists' implies a read-only operation, it doesn't specify whether this requires authentication, returns paginated results, includes metadata like bucket sizes/permissions, or has any rate limits. 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 that states exactly what the tool does without any wasted words. It's appropriately sized for a simple listing tool and is front-loaded with the core functionality.
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 insufficiently complete. For a listing tool in a storage context, it should ideally mention what information is returned (bucket names, creation dates, regions, etc.), whether results are filtered or paginated, and any authentication requirements. The current description leaves too many operational questions unanswered.
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 with 100% schema description coverage, so the schema already fully documents the input requirements. The description doesn't need to add parameter information, and it correctly doesn't attempt to describe nonexistent parameters. A baseline of 4 is appropriate for parameterless 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 storage buckets in the project'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_storage_objects' or 'list_tables', which would require more specific scope clarification.
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. With sibling tools like 'list_storage_objects' and 'list_tables' available, there's no indication of whether this tool is for bucket-level inventory versus object-level listing, or any prerequisites for its use.
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 returns a key 'if available', implying it may not always succeed, but doesn't specify error conditions, authentication requirements, or rate limits. For a tool that retrieves sensitive configuration data, this lack of detail on permissions or failure modes is a significant gap.
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. It is front-loaded with the main action ('Returns') and includes essential qualifiers ('configured', 'if available') without redundancy. Every word earns its place, making it highly concise and clear.
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 lacks details on usage context, behavioral traits, or output format. For a tool that retrieves a sensitive key, more information on security implications or error handling would improve completeness, though the minimal nature of the tool keeps it from being severely inadequate.
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%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it correctly doesn't mention any. Baseline is 4 for zero parameters, as the description appropriately focuses on the tool's purpose without unnecessary param 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 ('Returns') and resource ('configured Supabase service role key for this server'), making the purpose specific and understandable. It distinguishes from siblings like 'get_anon_key' by specifying 'service role key' rather than 'anon key', though it doesn't explicitly contrast them. The description avoids tautology and is not misleading.
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 prerequisite but doesn't explain what conditions make it available or when to choose this over other key-related tools. No explicit when/when-not or alternative recommendations are included.
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') and grouping behavior, but lacks critical details: it doesn't specify if this is a read-only operation, what 'accessible' means (permissions?), whether results are paginated, or the output format. For a tool with zero annotation coverage, 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 action ('Lists all accessible tables') and adds clarifying detail ('grouped by schema'). 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.
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 params, no output schema), the description is adequate but has gaps. It covers the basic purpose and grouping behavior, but without annotations or output schema, it should ideally mention the return format (e.g., list of table names with schemas) or any limitations. It's minimally viable but not fully 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, and schema description coverage is 100% (though empty). The description doesn't need to compensate for missing param info, and it correctly implies no inputs are required. A baseline of 4 is appropriate since there's nothing to document beyond the schema.
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 detail about grouping ('grouped by schema'). It doesn't explicitly differentiate from siblings like 'list_extensions' or 'list_storage_buckets', 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., database connection), compare to similar tools like 'list_extensions', or specify use cases (e.g., exploration vs. migration planning). This leaves the agent with minimal context for tool selection.
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 configuration and returns a preview, but lacks details on what 'preview' entails (e.g., partial secret, status message), potential errors (e.g., if not configured), or side effects (e.g., logging, rate limits). 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 ('Checks if the Supabase JWT secret is configured') and adds value with the outcome ('returns a preview'). There is no wasted verbiage or redundancy, making it highly concise and well-structured for quick understanding.
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, 100% schema coverage, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on the 'preview' output, error handling, or integration with sibling tools like get_anon_key. For a simple check tool, it meets basic needs but could be more complete by clarifying the return value or usage context.
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%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as the description doesn't compensate for missing param info, but none is required.
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 outcome ('returns a preview'), which distinguishes it from sibling tools 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, or related tools like get_anon_key for other secret checks. The context is implied (verifying JWT configuration), but no explicit usage scenarios or comparisons are given, leaving the agent to infer based on 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 the full burden of behavioral disclosure. It mentions the execution method (direct connection or RPC fallback) but lacks critical details such as whether this tool can perform destructive operations, what permissions are required, how results are returned, or any rate limits. For a tool that executes arbitrary SQL with no safety annotations, this is a significant gap.
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 purpose and implementation details without unnecessary words. It's front-loaded with the main action and avoids redundancy, making it easy to parse quickly.
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 (which can include reads, writes, or schema changes), the lack of annotations, and no output schema, the description is insufficient. It doesn't address safety, permissions, result formats, or error handling, leaving critical gaps for an AI agent to use this tool effectively in varied contexts.
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 both parameters (sql and read_only) with clear descriptions. The description doesn't add any meaningful semantic information beyond what's in the schema, such as SQL dialect specifics or read_only implications. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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 ('Executes an arbitrary SQL query') and the target resource ('against the database'), with additional implementation details about connection methods. It distinguishes itself from sibling tools like list_tables or get_database_stats by focusing on direct SQL execution rather than predefined operations.
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 mentioning 'direct database connection when available or RPC function as fallback,' suggesting this is a general-purpose SQL execution tool. However, it doesn't explicitly state when to use this versus alternatives like apply_migration for schema changes or list_tables for metadata queries, nor does it provide exclusions or prerequisites.
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 'Lists' but doesn't clarify if this is a read-only operation, what permissions are needed, how results are formatted, or if there are rate limits. The description is minimal and misses key behavioral details for a tool that interacts with database metadata.
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 without any fluff. It is front-loaded with the core action and resource, making it easy to parse quickly.
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 database migrations and the lack of annotations and output schema, the description is insufficient. It doesn't explain what information is returned (e.g., migration names, timestamps, statuses), how to interpret the results, or any limitations, leaving gaps for an AI agent to use the tool effectively.
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%, so there's no need for parameter details in the description. The description appropriately avoids redundant information, earning a baseline score of 4 for not adding unnecessary parameter semantics.
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 ('Lists') and resource ('applied database migrations recorded in supabase_migrations.schema_migrations table'), distinguishing it from siblings like list_tables or list_extensions by focusing on migrations. It provides precise scope and location information.
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 offers no guidance on when to use this tool versus alternatives like list_tables or apply_migration. It lacks context about prerequisites, such as whether migrations need to be applied first, or when this tool is most relevant in a workflow.
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 the tool returns a key but doesn't disclose behavioral traits like whether it's read-only, safe to call frequently, requires permissions, or what format the key is in (e.g., string, JSON).
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 resource, making it easy to parse 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 complete. However, it lacks context on usage scenarios or output details, which could help an agent understand when and how to apply it effectively.
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, so no parameter semantics are needed. The baseline for 0 parameters is 4, as the description adequately covers 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.
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 siblings like get_service_key or get_project_url by focusing on the anon key specifically.
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. It doesn't mention use cases like authentication setup, API access, or why one might choose this over get_service_key or other key-related tools.
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 but does not describe the return format, potential rate limits, authentication requirements, or whether it's a read-only operation. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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 without unnecessary words. It is front-loaded with the core action and resources, making it easy to understand at a glance.
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 retrieves statistical data. It does not explain what statistics are returned, their format, or any behavioral traits like performance impact or data freshness. This leaves the agent with insufficient context to use the tool effectively beyond knowing its general purpose.
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% (though empty). The description appropriately does not discuss parameters, as none exist, and instead focuses on what data is retrieved. This meets the baseline for a parameterless tool.
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 ('Retrieves statistics') and the exact resources involved ('database activity and the background writer from pg_stat_database and pg_stat_bgwriter'). It distinguishes itself from sibling tools like get_database_connections or list_tables by focusing on statistical metrics rather than connections or schema listings.
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 for monitoring database performance metrics, but does not explicitly state when to use this tool versus alternatives like get_database_connections for connection stats or execute_sql for custom queries. No exclusions or prerequisites are mentioned, leaving usage context somewhat open-ended.
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. It discloses key behavioral traits: the tool applies SQL within a transaction and records the migration, indicating it's a write operation with atomicity. However, it lacks details on permissions, error handling, or side effects beyond the transaction.
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 includes essential details (transactional recording). Every word contributes value with zero waste, 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 complexity (applies SQL migrations with versioning) and lack of annotations or output schema, the description is adequate but incomplete. It covers the purpose and transactional behavior but omits details on return values, error cases, or integration with sibling tools like list_migrations.
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 the parameters (name, sql, version). The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or constraints, resulting in a baseline score of 3.
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 the resource ('records it in the supabase_migrations.schema_migrations table'), distinguishing it from sibling tools like execute_sql or list_migrations by specifying the transactional recording aspect.
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 for applying SQL migrations with versioning, but does not explicitly state when to use this tool versus alternatives like execute_sql (for general SQL) or list_migrations (for viewing). It provides context but lacks explicit guidance on exclusions or prerequisites.
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 what the tool does but doesn't disclose behavioral traits like whether it requires specific permissions, returns a paginated list, includes system extensions, shows version information, or has any rate limits. The description is minimal and lacks 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 that directly states the tool's function with zero wasted words. It's appropriately sized and front-loaded, making it easy to understand immediately.
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), the description is adequate but minimal. It explains what the tool does but lacks context about return format, permissions needed, or relationship to other database listing tools. For a read-only listing tool with no annotations, more behavioral detail would be 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, and schema description coverage is 100%. With no parameters to document, the description appropriately doesn't discuss any. It focuses on the tool's purpose rather than parameter details, which is correct for a parameterless tool.
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 ('Lists') and resource ('all installed PostgreSQL extensions in the database'). It distinguishes from siblings like list_tables, list_auth_users, and list_migrations by specifying the exact type of database objects being listed.
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 to see installed extensions) but provides no explicit guidance on when to use this versus alternatives like execute_sql for custom queries or list_tables for different database objects. No exclusions or prerequisites are mentioned.
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 context beyond the input schema by warning about 'Password handling is insecure' and specifying requirements like 'Requires service_role key and direct DB connection', which are crucial for safe and correct usage. However, it doesn't detail potential side effects or response behavior, preventing a perfect 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 appropriately sized and front-loaded with the core purpose and critical warnings in just two sentences. Every sentence earns its place by conveying essential information without waste, making it highly efficient 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 complexity of a user update tool with 6 parameters, no annotations, and no output schema, the description is moderately complete. It covers key behavioral aspects like security warnings and prerequisites, but lacks details on return values, error handling, or full mutation implications, which would be beneficial for comprehensive understanding.
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 input schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining interactions between fields or usage nuances. This meets the baseline of 3 when 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 'Updates' and resource 'fields for a user in auth.users', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_auth_user' or 'delete_auth_user' beyond the update action, which keeps it from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context with 'Requires service_role key and direct DB connection', implying prerequisites for usage. However, it lacks explicit guidance on when to use this tool versus alternatives like 'create_auth_user' or 'delete_auth_user', leaving usage scenarios somewhat implied rather than clearly defined.
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 mentions the action 'Attempts to restart' (implying a mutation with potential failure) and a prerequisite, but lacks details on permissions needed, side effects, error handling, or rate limits. This is a moderate gap for a mutation tool without 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 that are front-loaded with the core action and essential prerequisite, with no wasted words. Every sentence adds value, making it efficient 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 complexity (a mutation with no annotations and no output schema), the description is moderately complete. It covers the purpose and a key prerequisite but lacks details on behavioral traits like success/failure outcomes or return values, which are important for agent invocation in this context.
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 inputs. The description does not need to add parameter semantics, and it appropriately avoids discussing parameters, earning a baseline score of 4 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 tool's purpose with the verb 'restart' and the resource 'pg_net worker', making it specific and actionable. However, it does not explicitly differentiate from sibling tools like 'list_extensions' or 'execute_sql', which could involve related operations, so it misses full sibling distinction.
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 'Requires the pg_net extension to be installed and available.' This gives explicit usage conditions, but it does not mention when not to use it or name alternatives among siblings, such as 'list_extensions' for checking installation status.
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. It indicates a read-only operation ('Returns') and specifies the data source ('configured... for this server'), but does not disclose behavioral traits like error conditions, authentication needs, or rate limits. It adequately describes the core behavior without contradictions.
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 function without unnecessary words. It is front-loaded with the key action and resource, making it easy to parse and understand immediately.
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 complete enough for basic understanding. However, it lacks details on the return format (e.g., string type, potential null values) or error handling, which could be helpful despite the low complexity.
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 schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter details beyond the schema, but this is appropriate given the lack of parameters, warranting a baseline score above minimum.
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 the exact resource ('configured Supabase project URL for this server'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'get_anon_key' or 'get_service_key' by focusing on the project URL rather than other configuration elements.
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 when the Supabase project URL is needed, but it does not explicitly state when to use this tool versus alternatives (e.g., other 'get_' tools for different configuration items) or any prerequisites. The context is clear but lacks explicit guidance on selection among siblings.
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 a plain password (security risk), and it operates directly on auth.users. The warning about insecurity and extreme caution adds valuable context beyond basic functionality, though it could mention permissions or side effects.
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 concise with only two sentences that each earn their place: the first states the purpose, and the second provides critical warnings. It's front-loaded with the core functionality and wastes no words, making it highly efficient for an AI agent 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 complexity (a write operation with security implications), no annotations, and no output schema, the description does well by covering the purpose and major risks. However, it lacks details on what the tool returns (e.g., user ID or confirmation) and doesn't mention prerequisites like admin permissions, leaving some gaps for a mutation tool.
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 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain the semantics of 'app_metadata' vs 'user_metadata'). This meets the baseline of 3 when the schema does the heavy lifting.
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 'delete_auth_user' which modify or remove users rather than create them. It uses precise language that leaves no ambiguity about the tool's 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 provides explicit guidance on when to use this tool ('Creates a new user') and includes a strong warning about security risks ('WARNING: Requires plain password, insecure. Use with extreme caution.'), which implicitly suggests caution and potential alternatives. However, it doesn't explicitly name alternative methods or specify when not to use it beyond the security warning.
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 mentions infrastructure dependencies ('direct DB connection'). It doesn't cover rate limits, error conditions, or what happens to associated data, but provides solid foundational 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 perfectly concise with two sentences that each earn their place: the first states the core functionality, the second specifies critical requirements. There's no wasted language or unnecessary elaboration.
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 destructive operation with no annotations and no output schema, the description does well by specifying the action, target, identifier, and critical requirements. It could be more complete by mentioning what 'deletes' entails (permanent removal vs soft delete) or what happens to user data, but it provides sufficient context for safe invocation given the tool's complexity.
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%, with the single parameter 'user_id' already well-documented in the schema as 'The UUID of the user to delete.' The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3 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 ('Deletes'), target resource ('a user from auth.users'), and identifier mechanism ('by their ID'). It distinguishes from siblings like 'create_auth_user' and 'update_auth_user' by specifying deletion rather than creation or modification.
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 about when to use this tool ('Deletes a user from auth.users by their ID') and mentions prerequisites ('Requires service_role key and direct DB connection'). However, it doesn't explicitly state when NOT to use it or name alternative tools for related operations like 'get_auth_user' 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.
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 describes key behaviors: it downloads a file to a specified path, returns platform information for path formatting, and has prerequisites (DATABASE_URL, Supabase CLI). It does not mention error handling, performance, or rate limits, but covers essential 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 appropriately sized and front-loaded, with the core purpose stated first, followed by key behaviors and prerequisites. Every sentence adds necessary information without redundancy, making it efficient and well-structured.
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 (involving file generation and external CLI usage), no annotations, and no output schema, the description is reasonably complete. It covers purpose, behavior, and prerequisites, but could benefit from details on error cases or output format beyond platform info.
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 minimal value beyond the schema by mentioning the use of 'supabase gen types' and platform-specific path examples, but does not provide additional semantic context for parameters like included_schemas or output_filename.
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') and resource ('using the Supabase CLI'), distinguishing it from sibling tools like list_tables or execute_sql. It precisely defines what the tool does without being tautological.
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 (for generating TypeScript types from a Supabase database schema) and mentions prerequisites (DATABASE_URL configuration, Supabase CLI installed). However, it does not explicitly state when not to use it or name specific alternatives among siblings.
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

selfhosted-supabase-mcp-basic-auth MCP server

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/abushadab/selfhosted-supabase-mcp-basic-auth'

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