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
Tools are cleanly separated into database, auth, storage, and functions domains, each with distinct actions. There is no overlap; e.g., supabase_insert, supabase_update, and supabase_upsert are clearly differentiated by their descriptions.
Naming Consistency4/5
All tool names use snake_case and follow a consistent 'supabase_' prefix. The pattern is mostly verb_noun (e.g., supabase_storage_create_bucket), but database tools like supabase_query and supabase_insert lack a domain prefix, making them slightly less consistent with the auth/storage/functions groups.
Tool Count4/5
21 tools is on the heavier side, but the server covers four distinct Supabase subsystems (database, auth, storage, functions), each with a reasonable set of operations. The count is justified for the broad scope, though it approaches the upper boundary.
Completeness4/5
The tool set provides solid CRUD coverage for database rows and users, plus file operations and RPC/function invocation. Minor gaps exist, such as missing storage bucket update/delete and lack of detailed schema inspection beyond listing tables, but these are not critical for most workflows.
Average 3.6/5 across 21 of 21 tools scored. Lowest: 2.6/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?
The description adds no behavioral context beyond annotations. readOnlyHint=false and idempotentHint=false already indicate possible mutation, but the description does not disclose potential side effects, permissions required, or return value behavior. 'Call via RPC' is essentially a restatement of the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the core purpose. However, it is extremely brief and omits critical details, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool invokes arbitrary Postgres functions, which can have varying side effects and return types. With no output schema, the description should explain expected return format and error behavior. It provides none, leaving the agent without essential operational 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 input schema already provides descriptions for both functionName and params, achieving 100% schema coverage. The description adds no additional parameter semantics, such as how params should be structured to match the Postgres function's arguments. Baseline 3 is appropriate because schema carries 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 action ('Call') and the resource ('a Postgres function'), with the mechanism 'via RPC' adding specificity. It distinguishes from common data operations like supabase_query or supabase_insert, but does not explicitly differentiate from supabase_functions_invoke (which likely calls Edge Functions), so it's not fully sibling-distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives. There is no 'use this when' or 'for standard operations, see ...' context. The description merely states what it does, leaving the agent to infer appropriate usage.
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?
Annotations include readOnlyHint=false, idempotentHint=false, and openWorldHint=true, which already signal that this is a non-idempotent write with potential side effects. The description adds no additional behavioral context such as authentication requirements, rate limits, or response handling, so it fails to add value beyond the 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 a single concise sentence, immediately stating the tool's function. There is no wasted text, and the structure is optimally front-loaded. It earns a perfect score because every word is necessary and clear.
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?
This tool has 4 parameters including nested objects and is a non-idempotent operation, yet the description gives no context about expected response format, error behavior, or prerequisites. The annotations and schema provide some safety and parameter info, but for an invocation tool with no output schema, the description is too thin to be considered complete.
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 input schema provides full descriptions for all 4 parameters (100% coverage), including the functionName, method enum, body object, and headers object. The description itself adds no parameter-level information, but since the schema already carries that load, a baseline score of 3 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 'Invoke' and the resource 'Supabase Edge Function', making the tool's core purpose obvious. It is distinct from the sibling tool supabase_rpc (which invokes database RPCs) by explicitly naming Edge Functions, though it doesn't call out that 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 other tools like supabase_rpc, or any context involving prerequisites or edge cases. There is no mention of alternatives or exclusions, so the agent receives no usage direction beyond the basic purpose.
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?
Annotations already provide readOnlyHint=false and destructiveHint=true, but the description adds no additional behavioral context (e.g., whether it overwrites, requires unique names, or returns a bucket object). The description neither contradicts nor enriches the annotations, leaving the agent with only the minimal high-level statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no redundancy. It is appropriately brief for a simple operation, though it omits additional context; this is conciseness, not under-specification.
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?
With no output schema and only a five-word description, the tool lacks critical context about return values, error behavior, or idempotency. The annotations hint at destructiveness but do not clarify the creation result, making the description incomplete for an agent to predict outcomes beyond the basic action.
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 input schema has 100% coverage with clear descriptions for all four parameters, so the schema carries the semantic load. The description adds no extra parameter-level detail, so the baseline of 3 is appropriate for high 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 'Create a new storage bucket' uses a specific verb and resource, clearly stating the action and object. It distinguishes from sibling storage actions like list, upload, download, and delete by naming the create operation for buckets.
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 on when to use this tool versus alternatives such as supabase_storage_list_buckets or supabase_storage_upload. There is no mention of prerequisites, use cases, or exclusions, leaving the agent without contextual 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the write operation is known. The description adds no additional behavioral context such as RLS implications, return values, or conflict error semantics. It merely restates the insert action without enriching beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose without any redundancy or filler. It is front-loaded and efficiently communicates the core functionality.
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?
The description is adequate for a simple insert tool but has clear gaps: it does not mention return values or error behavior, which matters because no output schema is present. It also does not clarify how onConflict relates to upsert behavior, though the schema provides that. These gaps prevent a higher score.
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 input schema covers 100% of parameters with descriptions for table, data, and onConflict. The description adds no extra meaning beyond the schema; 'one or more rows' is already reflected in the schema's anyOf for data. Baseline 3 applies because 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 action ('Insert'), the resource ('Supabase table'), and the scope ('one or more rows'). It distinguishes from siblings like supabase_update (which modifies existing rows) and supabase_upsert (which also inserts but with conflict handling), though it doesn't explicitly mention that 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?
No guidance is provided on when to use this tool versus alternatives like supabase_upsert or supabase_update. The description only states the basic action without mentioning conflict handling, prerequisites, or exclusions. The existence of supabase_upsert makes this absence particularly noticeable.
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?
Annotations already declare readOnlyHint and idempotentHint, so the description adds no additional safety context. It also introduces ambiguity with 'database schema', which could be confused with the 'schema' parameter, and it does not disclose return format or whether system tables are included.
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 sentence with no redundancy. It is appropriately sized for the tool's simplicity, front-loading the action ('List') and the resource ('tables').
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?
The tool is simple (one optional parameter, no output schema), and the description covers the basic operation. However, it omits what the response contains (e.g., table names, metadata, pagination), which is a gap for a tool that returns a list.
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 already clearly documented as 'Schema to list tables from (default: public)'. The tool description adds no extra meaning to the parameter, so the baseline of 3 applies.
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 'List all tables in the database schema' uses a specific verb ('List') and resource ('tables'), making the tool's purpose clear. It is distinct from sibling tools like supabase_query or supabase_insert, and there is no competing table-listing sibling.
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. There is no mention of prerequisites, such as discovering tables before querying, or exclusions like system schemas. The description only states what it does, not when to invoke it.
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?
The description adds no behavioral context beyond the basic creation operation. It does not mention confirmation emails, required permissions, or state changes, relying entirely on the annotations which indicate destructiveHint=true. With annotations present, the low bar is not met because no additional behavioral insight is provided.
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 concise sentence with no filler. It effectively communicates the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and complex auth behavior, the description is too minimal. It lacks information about return values, confirmation flows, or error conditions, making it insufficient for an agent to fully anticipate the tool's behavior.
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 coverage is 100%, so the schema fully describes each parameter. The description adds a slight semantic clue by indicating the email/password or phone combination, but it doesn't clarify required combinations or edge cases.
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 a specific action (create) and resource (a user), and specifies the authentication methods supported (email/password or phone). This distinguishes it from sibling tools like supabase_auth_update_user and supabase_auth_delete_user.
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 offers no explicit guidance on when to use this tool versus alternatives such as supabase_insert or supabase_rpc. The auth namespace and parameter schema imply its purpose, but no when-to-use or when-not-to-use guidance is 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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds no extra behavioral context beyond what the annotations provide, such as irreversibility, cascading effects, or required admin permissions. For a destructive operation, this lack of additional disclosure 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, concise sentence that directly states the tool's purpose. There is no wasted verbiage, and the essential information is front-loaded.
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 simple 1-parameter delete operation, the description combined with the schema and annotations provides adequate context. The destructiveHint annotation covers the risk profile, and the parameter is fully documented. It would benefit from a mention of irreversibility, but overall completeness is sufficient for the tool's low 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 input schema already fully describes the only parameter (userId) with 'User ID (UUID) to delete', providing 100% schema description coverage. The description does not add further meaning beyond the schema, but it is consistent with the parameter's documented purpose. Baseline 3 is appropriate.
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 'Delete a user by their ID' clearly states the action (delete), the resource (user), and the key parameter (ID). It is specific and distinguishes this tool from sibling tools like supabase_delete (which deletes table rows) and supabase_auth_update_user (which updates rather than deletes).
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 does not mention exclusions, prerequisites, or scenarios where supabase_delete or other auth tools might be more appropriate. Usage is only implied by the tool name and sibling context.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, which the description does not contradict. The description adds field-level detail but does not disclose additional behavioral traits like whether email updates trigger verification, whether password changes invalidate sessions, or whether it returns the updated user. It adds minimal value beyond the 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 a single, concise sentence that front-loads the action and key resources. Every word earns its place, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive update tool with complete schema coverage, the description is minimally adequate. However, with no output schema, it does not specify the return value or side effects, and the wording 'or metadata' could mislead about updating multiple fields at once. The annotations cover the destructive nature, but more context about behavioral outcomes would improve completeness.
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 coverage is 100% with all parameters described, so the description does not need to explain them. It lists a subset of fields in prose but adds no meaning beyond the schema. The nested metadata objects are only mentioned as 'metadata', not elaborated.
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 uses the specific verb 'Update' and identifies the resource as a 'user' with concrete fields (email, password, phone, metadata). This clearly distinguishes it from sibling auth tools like create_user, get_user, and delete_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, such as supabase_update (generic table update) or other auth-specific tools. It does not mention exclusions or prerequisites, so the agent must infer usage solely from the tool name and sibling context.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds that operations are limited to rows 'matching the given filters', which is useful scope context. However, it does not disclose how multiple filters are combined (e.g., AND semantics) or the irreversibility beyond the annotation.
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?
A single clear sentence that front-loads the action and object. No redundant words.
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 simple tool, good annotations, and complete schema, the description is mostly sufficient. It could mention return values or multi-filter semantics, but these are not critical for a delete operation. Overall adequate.
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 input schema already provides descriptions for both parameters with 100% coverage, so the description adds little beyond restating 'filters'. Baseline 3 is appropriate.
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 uses a specific verb 'delete' with the resource 'Supabase table' and clearly restricts scope to 'matching the given filters'. This distinguishes it from sibling tools like supabase_update or supabase_query.
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 explicit guidance is given about when to use this versus other tools. It doesn't mention alternatives or caution against using for non-destructive operations. The description simply states the action, leaving the agent to infer usage context.
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?
The annotations include destructiveHint=true, so the destructive nature is already disclosed. The description merely says 'Delete' without adding extra behavioral context like permanence, partial failure, or permission requirements. It is consistent with annotations but contributes no additional 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, front-loaded sentence with no unnecessary words. Every word earns its place.
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 simple delete tool, the combination of description, schema (100% coverage), and destructiveHint annotation covers the essential context. It lacks explicit mention of irreversibility or behavior for missing files, but these are not critical given the annotation disclosure.
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 input schema describes both parameters (bucket and paths) with clear descriptions, giving 100% coverage. The description adds no parameter-specific details, so baseline 3 is appropriate.
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 'Delete files from a storage bucket' clearly identifies the verb (delete), resource (files), and location (storage bucket). It distinguishes this from sibling supabase_delete (database rows) and other storage operations like move/upload.
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 supabase_delete or supabase_storage_move. No exclusions, prerequisites, or alternative scenarios 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?
The description conveys that the operation mutates state, consistent with the destructiveHint=true annotation. It adds the constraint that the move happens 'within a storage bucket', which matches the single bucket parameter. However, it does not disclose additional behavioral traits like overwrite behavior or that the source is removed, though these are implied by the word 'move'.
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, front-loaded sentence with no fluff or redundancy. It states the operation and resource efficiently, earning a high score for conciseness and structure.
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 simple three-parameter move operation with annotations and no output schema, the description is nearly complete. It defines the main purpose and the within-bucket scope. It could explicitly mention that the source is removed or that the destination must not already exist, but these are reasonably inferred from the word 'move' and the parameter set.
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 descriptions cover 100% of parameters (bucket, fromPath, toPath). The tool description adds no extra semantics about parameter usage, such as path formatting or relative/absolute requirements. With high schema coverage, the baseline of 3 is appropriate.
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 operation with specific verbs 'move or rename' and identifies the resource as 'a file within a storage bucket'. This distinguishes it from sibling tools like upload, download, delete, and list, all of which have different purposes. The title 'Move File' reinforces the action.
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 gives no explicit guidance on when to use this tool versus alternatives. It lacks any mention of prerequisites, such as the destination path being available or the source file existing, and does not contrast with upload/delete combinations or other storage operations. Usage is only implied by the verb itself.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat that. The description adds the features (filters, ordering, pagination) but does not disclose any negative behaviors or additional context beyond what the annotations cover.
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, focused sentence that immediately conveys the tool's primary purpose. There is no filler or redundant 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?
While the schema is comprehensive, the description leaves out key behavioral details such as how multiple filters are combined (AND vs OR) and the default return format. The read-only annotation and idempotency are helpful, but the complexity of this query tool warrants a bit more explanation, making it adequate but incomplete.
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 each parameter having a description. The tool description does not add any semantic meaning beyond summarizing the query capabilities; it neither clarifies filter combination nor parameter format, so baseline 3 is appropriate.
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 verb 'Select', the resource 'rows from a Supabase table', and the capabilities 'filters, ordering, and pagination'. It distinctly differentiates from sibling write tools like supabase_insert and supabase_update.
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 read-only row selection but does not explicitly provide when-to-use guidance or alternatives to other siblings. It is clear enough to infer this is the query tool, but no exclusions or alternatives 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?
Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds a path-scoping detail ('at a given path') but does not disclose pagination behavior, sorting, or return format. No contradiction with 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 a single concise sentence that states the core function with no wasted words. It is appropriately sized for the tool's simplicity.
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?
The description is minimal for a tool with 5 parameters and a nested sortBy object, and there is no output schema. It does not mention pagination defaults, sorting capability, or the shape of the returned list, relying on the schema for parameter details.
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 coverage is 100%, so all parameters are described with defaults and types. The description does not add meaning beyond the schema, which already documents path, limit, offset, and sortBy.
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 action ('List files') and the resource ('storage bucket at a given path'), distinguishing it from sibling tools like list_buckets. It is specific and not a tautology.
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 (if you need to list files in a bucket, use this) but does not provide explicit when/when-not guidance or name alternatives. There is no exclusion or comparison to other storage tools.
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?
Annotations already declare readOnlyHint=false and destructiveHint=true, and the description adds the base64-encoded content requirement. However, it does not disclose overwrite behavior (e.g., upsert), authentication needs, or error/failure semantics, leaving some behavioral gaps beyond what annotations provide.
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, front-loaded sentence with no fluff. It efficiently communicates the core purpose and key constraint ('base64-encoded content'). Every word earns its place.
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?
The schema and annotations cover parameters and safety, but the description lacks information about return values or success/failure behavior (no output schema exists). It also does not mention upsert semantics, though that is in the schema. Overall, it is minimally sufficient but with notable gaps for a storage upload 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 all parameters are well-documented. The description adds no new parameter semantics beyond reiterating base64-encoded content, which the schema already specifies for fileBody. Baseline 3 is appropriate given full 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 action ('Upload') and the resource ('a file to a storage bucket'), with a parenthetical about base64 content. This distinguishes it from sibling storage tools like download, delete, and move. The verb+resource structure is specific and unambiguous.
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 uploading base64-encoded files to buckets but does not explicitly state when to use it vs alternatives. It gives no exclusions or references to sibling tools, though the base64 constraint provides some contextual guidance. This is implied usage, not explicit guidance.
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?
Annotations mark destructiveHint true, and the description adds the upsert semantics ('insert or update on conflict'), which explains the mutation behavior. However, it does not disclose consequences like partial failures, required permissions, or impact on existing data beyond the conflict. No contradiction with 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?
One concise sentence that front-loads the core verb and resource. No filler 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?
With no output schema and a destructive mutation, the description lacks detail on return values, error handling, and when to prefer this over supabase_update/insert. The existing schema and annotations cover parameter definitions and safety flags, but contextual guidance is minimal.
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 descriptions cover all 4 parameters (100%), so the description adds no parameter-level details beyond what's in the schema. The baseline for high schema coverage is 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 uses the specific verb 'upsert' and identifies the resource as 'rows in a Supabase table.' It distinguishes from siblings by noting 'insert or update on conflict,' which clearly separates it from supabase_insert and supabase_update.
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 the tool is for insert-or-update scenarios but provides no explicit when-to-use guidance or comparison with alternatives. Sibling tools like supabase_insert and supabase_update exist, but no exclusions are stated.
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?
Annotations already convey that this is a read-only, idempotent operation. The description reinforces this by saying 'get' but adds no new behavioral details such as error handling, return format when the user is not found, or auth requirements. It does not contradict the 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 a single, concise sentence that directly states the tool's purpose. It is front-loaded with the verb and noun, and contains no unnecessary words or repetition.
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 simple one-parameter getter with read-only annotations, the description is sufficient. It covers what the tool does and the key identifier. However, it could mention whether the tool returns null or throws on missing users, but given the simplicity, the current level of detail is acceptable.
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 input schema already fully documents the only parameter (userId) with its format (UUID). The description does not add any semantics beyond what the schema provides. With 100% schema coverage, the baseline of 3 is appropriate.
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 is specific and unambiguous: it states the action (get) and the resource (a single user by ID). It clearly distinguishes from siblings like list_users, create_user, update_user, and delete_user because it focuses on retrieval of one user by ID.
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 when to use the tool (when you have a specific user ID and need that user's details), but it does not explicitly state when not to use it or mention alternatives like list_users for multiple users. The purpose is clear enough for an agent to infer the usage context, but no direct guidance is provided.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, read-only operation. The description adds no additional behavioral context (e.g., that it constructs a URL rather than transferring file data, or whether the file must be publicly accessible), but it does not contradict the 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 a single, concise sentence that front-loads the action and object. Every word contributes to clarity, with no redundancy 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?
The tool is simple, and the annotations cover the safety profile. However, there is no output schema, and the description does not explicitly state that the return value is the URL string or mention any caveats about public access. This is a minor gap, but the overall purpose is sufficiently inferable.
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 input schema provides descriptions for both parameters ('Bucket name' and 'File path within the bucket'), resulting in 100% schema coverage. The description adds no extra parameter details beyond what the schema already states, so the baseline of 3 is appropriate.
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 uses the specific verb 'Get' with the resource 'public URL for a file in a storage bucket.' This precisely distinguishes it from sibling tools like download (which fetches content) and move/delete. The purpose is unambiguous and clearly differentiated.
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?
No explicit when-to-use guidance or alternatives are provided. The intended usage (when a shareable URL is needed) is implied by the tool name and description, but the text does not mention prerequisites (e.g., bucket must be public) or contrast it with download/other file access methods. This is minimal but not misleading.
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?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds the behavioral context that this lists all users (no filtering) and supports pagination, which is useful for managing large result sets. However, it does not disclose response shape or potential side effects, but these are largely absent for a read-only list.
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, concise sentence that front-loads the key information. No filler or redundancy; every word contributes to specifying the tool's function.
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 simple list tool with well-covered parameters and read-only annotation, the description is nearly complete. It could mention the return format (e.g., array of user objects) or that defaults apply, but the tool name and schema make these largely inferable.
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 coverage is 100%, with page and perPage already having descriptive labels and defaults. The description's 'with pagination' adds no new meaning beyond the schema, so the baseline of 3 is appropriate.
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 'List all users with pagination' uses the specific verb 'List' and resource 'users', clearly distinguishing it from sibling tools like auth_get_user (single user) and auth_create_user. The scope 'all users' and pagination detail make the purpose unambiguous.
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 clearly states the tool lists all users with pagination, implying use when a full or paginated list of auth users is needed. While it does not explicitly mention alternatives or exclusions, the context is clear given sibling tools; no conflicting guidance exists.
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?
The description reveals that the tool returns base64-encoded content, a key behavioral detail that goes beyond the annotations. The readOnlyHint and idempotentHint annotations align with this read operation, with no contradictions. It does not cover error conditions or permission requirements, but for a read-only operation this is acceptable.
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, concise sentence that immediately states the action and key output detail. Every word earns its place, with no repetition of schema or annotation information.
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?
With only two required parameters and a simple read operation, the description covers the essential behavior and return format. The output schema is absent, but the description explicitly notes 'returns base64', filling that gap. Annotations provide safety and idempotency context, making this adequately complete for 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?
Both parameters (bucket and path) are fully described in the schema with clear explanations ('Bucket name', 'File path within the bucket'). The tool description adds no additional parameter information, so the schema already provides complete semantic coverage, meriting 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 uses the specific verb 'Download' with a clear resource 'file from a storage bucket'. The parenthetical '(returns base64)' distinguishes this from sibling tools like supabase_storage_get_public_url or supabase_storage_delete, making the purpose unambiguous.
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 the tool is used when you need the actual file content, but it does not explicitly state when to use this versus alternatives like get_public_url or list_files. There is no mention of exclusions or preferred use cases, so guidance is limited to implied usage.
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?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation risk is known. The description adds that updates are applied to rows matching the supplied filters, which clarifies the scope of the destructive action.
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, concise sentence that immediately conveys the action and scope. No filler or redundancy.
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 moderate complexity, the detailed schema, and annotations already covering destructive behavior, the description is sufficient for basic tool selection. The only gap is the return value, which is not described, but this is not critical for choosing the 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?
All three parameters (table, data, filters) are documented in the schema with 100% coverage, so the description does not need to add parameter details. The description refers to filters but does not add new semantic information beyond the schema.
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 it updates rows in a Supabase table based on filters. It distinguishes from sibling tools like insert, delete, and upsert by using the specific verb 'update' and the filter-based scope.
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 implies usage for updating existing rows that match filters, providing clear context. It does not explicitly mention when to use alternatives like upsert or delete, but the purpose is unambiguous.
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?
The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and determinism. The description adds the 'all' scope—indicating no filtering or pagination—beyond the annotations, which is a useful behavioral trait.
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, front-loaded sentence that conveys exactly the necessary information with zero waste. It is concise without sacrificing clarity.
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?
The tool is simple with no parameters and no output schema, but the description does not indicate what the response will look like (e.g., fields returned for each bucket). For a listing operation, this leaves some ambiguity about return values, so it is 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 zero parameters, and schema coverage is 100% (empty object). With no parameters to explain, the description doesn't need to add parameter detail, and the baseline of 4 applies.
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 'List all storage buckets' uses a specific verb ('list') and resource ('storage buckets'), clearly distinguishing this from sibling tools like create_bucket or list_files. It fully and unambiguously states the tool's purpose.
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: whenever you need to see all storage buckets. While it doesn't explicitly name alternatives, the scope is evident and there are no competing list-bucket tools among the siblings, so exclusionary guidance is unnecessary.
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:

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

Score Badge

Copy to your README.md:

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

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/Joseph19820124/supabase-mcp-server'

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