Enables comprehensive management of self-hosted Supabase instances including database migrations, edge functions deployment, storage bucket management, authentication configuration, realtime settings, and health monitoring.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Supabase Coolify MCP Server deploy the latest database migration to production"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Install directly in your favorite AI coding tool:
Claude Code:
claude mcp add supabase-coolify -- npx -y supabase-coolify-mcp-serverNote: After installation, you'll need to configure the required environment variables. See Configuration below.
A comprehensive TypeScript MCP (Model Context Protocol) server for managing self-hosted Supabase on Coolify. This server enables AI agents to fully deploy migrations, push edge functions, configure services, and manage Supabase deployments with ease.
📦 NPM Package • 📚 Documentation • 🚀 Quick Start
Related MCP server: Supabase MCP Server - Self-Hosted Edition
Database Migrations: Deploy, track, rollback, and manage database migrations
Migration Rollback: Safely rollback migrations with down SQL support
Supabase CLI Integration: Full CLI integration for local development and deployment
Edge Functions: Deploy, invoke, monitor, and delete edge functions
Storage Management: Create and manage storage buckets
Auth Configuration: Configure authentication providers and settings
Realtime Configuration: Manage realtime service settings
Health Monitoring: Check status of all Supabase services
Type Generation: Generate TypeScript types from database schema
Input Validation: Zod-based validation for all tool inputs
Health Checks: Automatic startup checks and verification tool
Error Handling: Comprehensive error messages with troubleshooting hints
Type Safety: Full TypeScript support throughout
Application Management: List, deploy, start, stop, and restart applications
Service Management: Control Coolify services
Database Management: Manage Coolify-hosted databases
Environment Variables: Update application configuration securely
Logs: Access application logs for debugging
One-Click Deployment: Deploy complete Supabase instances on Coolify
Configuration Management: Update deployment settings dynamically
Status Monitoring: Track deployment health and status
Node.js >= 18.0.0
A Coolify instance (self-hosted or cloud)
Coolify API token with appropriate permissions
A self-hosted Supabase instance (or ready to deploy one)
Install globally via NPM:
npm install -g supabase-coolify-mcp-serverOr use directly with npx (no installation needed):
npx supabase-coolify-mcp-serverPackage: https://www.npmjs.com/package/supabase-coolify-mcp-server
Clone and build from GitHub:
git clone https://github.com/dj-pearson/supabase-coolify-mcp-server.git
cd supabase-coolify-mcp-server
npm install
npm run buildCreate a .env file or set the following environment variables:
# Required: Coolify Configuration
COOLIFY_API_URL=http://localhost:8000
COOLIFY_API_TOKEN=your-coolify-api-token-here
# Required: Supabase Configuration
SUPABASE_URL=https://your-supabase-instance.example.com
SUPABASE_SERVICE_ROLE_KEY=your-supabase-service-role-key
# Optional: Coolify Team
COOLIFY_TEAM_ID=optional-team-id
# Optional: Supabase Additional Config
SUPABASE_ANON_KEY=your-supabase-anon-key
SUPABASE_PROJECT_ID=your-project-id
SUPABASE_PROJECT_REF=your-project-ref
SUPABASE_FUNCTIONS_URL=https://your-supabase-instance.example.com/functions/v1
# Optional: Direct Database Access
SUPABASE_DB_HOST=localhost
SUPABASE_DB_PORT=5432
SUPABASE_DB_NAME=postgres
SUPABASE_DB_USER=postgres
SUPABASE_DB_PASSWORD=your-db-passwordLog into your Coolify instance
Navigate to "Keys & Tokens" > "API tokens"
Click "Create New Token"
Select permissions (recommended: * for full access)
Copy the generated token
For self-hosted Supabase:
Log into your Supabase dashboard
Go to Settings > API
Copy the service_role key (keep this secure!)
Or from your Supabase deployment environment variables:
echo $SERVICE_ROLE_KEYThe MCP server requires environment variables to connect to Coolify and Supabase.
Recommended Setup (Works for Everyone):
Add environment variables directly to your MCP configuration:
{
"mcpServers": {
"supabase-coolify": {
"command": "npx",
"args": ["-y", "supabase-coolify-mcp-server"],
"env": {
"COOLIFY_API_URL": "http://your-coolify-url:8000",
"COOLIFY_API_TOKEN": "your-actual-token",
"SUPABASE_URL": "https://your-supabase-url.com",
"SUPABASE_SERVICE_ROLE_KEY": "your-actual-service-role-key"
}
}
}
}Replace the placeholder values with your actual credentials!
The server supports three methods for providing environment variables (in priority order):
MCP Config env section ⭐ RECOMMENDED - Works for everyone, self-contained
System environment variables - For advanced users who want credentials outside config
.env file with wrapper script - For local development only (not scalable)
For detailed setup instructions for each method, see: MCP_CONFIGURATION.md
Common Mistake: ❌ Leaving placeholder values like https://your-supabase-instance.example.com
Solution: ✅ Replace ALL placeholders with your actual URLs and credentials!
Add to your Claude Desktop configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"supabase-coolify": {
"command": "npx",
"args": ["-y", "supabase-coolify-mcp-server"],
"env": {
"COOLIFY_API_URL": "http://localhost:8000",
"COOLIFY_API_TOKEN": "your-coolify-api-token",
"SUPABASE_URL": "https://your-supabase-instance.example.com",
"SUPABASE_SERVICE_ROLE_KEY": "your-service-role-key"
}
}
}
}First install globally:
npm install -g supabase-coolify-mcp-serverThen configure:
{
"mcpServers": {
"supabase-coolify": {
"command": "supabase-coolify-mcp",
"env": {
"COOLIFY_API_URL": "http://localhost:8000",
"COOLIFY_API_TOKEN": "your-coolify-api-token",
"SUPABASE_URL": "https://your-supabase-instance.example.com",
"SUPABASE_SERVICE_ROLE_KEY": "your-service-role-key"
}
}
}
}# Using environment variables
export COOLIFY_API_URL="http://localhost:8000"
export COOLIFY_API_TOKEN="your-token"
export SUPABASE_URL="https://your-instance.example.com"
export SUPABASE_SERVICE_ROLE_KEY="your-key"
npm run dev
# Or with .env file
npm run devnpm run build
npm startlist_migrationsList all database migrations with their status.
// No parameters requireddeploy_migrationDeploy a new database migration.
{
"sql": "CREATE TABLE users (id SERIAL PRIMARY KEY, email TEXT);",
"name": "create_users_table"
}execute_sqlExecute raw SQL query on the Supabase database.
{
"sql": "SELECT * FROM users LIMIT 10;"
}get_migration_statusGet status of a specific migration.
{
"version": "20231201120000"
}list_edge_functionsList all deployed edge functions.
deploy_edge_functionDeploy a new edge function.
{
"name": "hello-world",
"code": "export default function handler(req) { return new Response('Hello World'); }",
"verify_jwt": true
}delete_edge_functionDelete an edge function.
{
"name": "hello-world"
}get_edge_function_logsGet logs for an edge function.
{
"name": "hello-world",
"limit": 100
}invoke_edge_functionInvoke an edge function.
{
"name": "hello-world",
"payload": { "key": "value" }
}list_storage_bucketsList all storage buckets.
create_storage_bucketCreate a new storage bucket.
{
"id": "avatars",
"public": true,
"file_size_limit": 5242880
}delete_storage_bucketDelete a storage bucket.
{
"id": "avatars"
}get_auth_configGet authentication configuration.
update_auth_configUpdate authentication configuration.
{
"config": {
"site_url": "https://myapp.com",
"enable_signup": true
}
}check_supabase_healthCheck health of all Supabase services.
get_supabase_versionGet Supabase version information.
verify_setup ⭐Verify system setup and check health of all services (Coolify, Supabase, CLI).
This comprehensive tool checks:
Coolify connection and authentication
Supabase connection and authentication
Database accessibility
CLI availability
Response times and service status
Returns: Detailed health report with recommendations for any issues found.
See docs/VERIFICATION.md for complete verification guide.
list_coolify_applicationsList all Coolify applications.
get_coolify_applicationGet details of a specific application.
{
"uuid": "app-uuid-here"
}update_coolify_application_envUpdate application environment variables.
{
"uuid": "app-uuid-here",
"env": {
"NODE_ENV": "production",
"API_KEY": "secret"
}
}deploy_coolify_applicationDeploy a Coolify application.
{
"uuid": "app-uuid-here"
}start_coolify_application / stop_coolify_application / restart_coolify_applicationControl application lifecycle.
{
"uuid": "app-uuid-here"
}get_coolify_logsGet application logs.
{
"uuid": "app-uuid-here",
"lines": 100
}deploy_supabase_to_coolifyDeploy a complete Supabase instance on Coolify.
{
"name": "my-supabase",
"config": {
"postgres_version": "15",
"enable_realtime": true,
"enable_storage": true,
"enable_auth": true,
"custom_domain": "https://supabase.myapp.com",
"environment_variables": {
"CUSTOM_VAR": "value"
}
}
}update_supabase_deploymentUpdate an existing Supabase deployment.
{
"uuid": "app-uuid-here",
"config": {
"enable_graphql": true
}
}get_deployment_statusGet status of a Supabase deployment.
{
"uuid": "app-uuid-here"
}The server exposes these resources for MCP clients:
supabase://migrations - All database migrations
supabase://edge-functions - All edge functions
supabase://storage-buckets - All storage buckets
supabase://auth-config - Authentication configuration
supabase://health - Service health status
coolify://applications - All Coolify applications
coolify://services - All Coolify services
coolify://databases - All Coolify databases
Never commit API tokens to version control
Use environment variables for sensitive data
Restrict API token permissions to minimum required
Rotate tokens regularly
Use service role key only on secure servers
Enable JWT verification for edge functions
Validate all inputs (automatic with Zod schemas)
Verify setup before production deployments
Set appropriate file permissions on configuration files:
chmod 600 ~/.env
chmod 600 ~/Library/Application\ Support/Claude/claude_desktop_config.json# Run type checking
npm run typecheck
# Run linter
npm run lint
# Build project
npm run buildAfter starting the server, verify everything is working:
# Start the server
npm start
# Then ask Claude:
"Run verify_setup to check if everything is configured correctly"See docs/VERIFICATION.md for complete verification guide.
Before reporting issues or if you're having connection problems, use the built-in diagnostic tool:
Run the automated diagnostic tool to check your setup:
# Using npm
npm run diagnose
# Or on Windows
.\diagnose.ps1
# Or on Linux/Mac
./diagnose.shThe diagnostic tool will automatically check:
✅ .env file existence and configuration
✅ Required environment variables
✅ Coolify API connection and authentication
✅ Supabase connection and authentication
✅ All Supabase services health
✅ Network connectivity
🟢 ALL CHECKS PASSED - MCP Server should work correctly
✅ Passed: 10
❌ Failed: 0
⚠️ Warnings: 0❌ .env file NOT found!Fix: cp env.example .env then edit with your credentials
❌ ENV: COOLIFY_API_TOKEN: Contains placeholder valueFix: Replace your-coolify-api-token-here with actual token from Coolify Dashboard → Keys & Tokens
❌ Supabase Authentication: Invalid service role keyFix: Make sure you're using the service_role key, NOT the anon key!
Get it from: Supabase Dashboard → Settings → API → service_role key
❌ Coolify Connection: ECONNREFUSEDFix: Verify Coolify is running and accessible at the configured URL
Coolify API Token:
Coolify Dashboard → Profile → Keys & Tokens → API Tokens
Click "Create New Token"
Copy the token (you won't see it again!)
Add to .env as COOLIFY_API_TOKEN
Supabase Service Role Key:
Supabase Cloud: Dashboard → Settings → API → Copy service_role key
Self-hosted: Check Coolify deployment environment variables for SERVICE_ROLE_KEY
For detailed troubleshooting, see:
START_HERE.md - Quick start with diagnostics
DIAGNOSE_NOW.md - Step-by-step diagnosis
TROUBLESHOOTING.md - Comprehensive troubleshooting guide
Error: Missing required environment variables: COOLIFY_API_URL, COOLIFY_API_TOKEN
Solution: Ensure all required environment variables are set. Check your .env file or Claude Desktop configuration.
Error: Failed to connect to Coolify API
Solution:
Verify Coolify instance is running
Check API URL is correct (include http:// or https://)
Ensure API token has proper permissions
Check network connectivity
Error: Unauthorized or 401
Solution:
Verify API tokens are correct
Check token hasn't expired
Ensure token has required permissions
Solution:
Restart Claude Desktop
Check configuration file path is correct for your OS
Verify JSON syntax in configuration
Check server logs for errors
Run with debug output:
DEBUG=* npm start// Using the MCP tool
deploy_supabase_to_coolify({
name: "production-supabase",
config: {
postgres_version: "15",
enable_realtime: true,
enable_storage: true,
custom_domain: "https://api.myapp.com"
}
})deploy_migration({
name: "add_user_profiles",
sql: `
CREATE TABLE user_profiles (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
user_id UUID REFERENCES auth.users(id),
display_name TEXT,
avatar_url TEXT,
created_at TIMESTAMP DEFAULT NOW()
);
`
})deploy_edge_function({
name: "send-email",
code: `
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'
serve(async (req) => {
const { to, subject, body } = await req.json()
// Send email logic here
return new Response(JSON.stringify({ success: true }))
})
`,
verify_jwt: true
})// Check overall health
check_supabase_health()
// Get specific deployment status
get_deployment_status({ uuid: "your-app-uuid" })
// View logs
get_coolify_logs({ uuid: "your-app-uuid", lines: 100 })Contributions are welcome! Please feel free to submit a Pull Request.
MIT
NPM Package: https://www.npmjs.com/package/supabase-coolify-mcp-server
GitHub Repository: https://github.com/dj-pearson/supabase-coolify-mcp-server
Coolify: https://coolify.io - Self-hostable Heroku/Netlify alternative
Supabase: https://supabase.com - Open source Firebase alternative
Model Context Protocol: https://modelcontextprotocol.io - MCP specification
For issues and questions:
Check the troubleshooting section
Note: This MCP server is designed for self-hosted Supabase instances on Coolify. It provides comprehensive management capabilities while maintaining security through environment variables and proper token handling.
Check if Supabase CLI is installed and get version
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only implies a read-only check without stating it's non-destructive, nor does it mention any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 8 words, no fluff; sufficiently structured for a simple check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-param tool, it conveys purpose but lacks detail on output format or version string; somewhat adequate but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0), so schema coverage is 100% trivially; description adds no parameter info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'check if installed' and resource 'Supabase CLI', distinguishing it from sibling tools like check_supabase_health or get_supabase_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like check_supabase_health or get_supabase_version; lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check health of all Supabase services
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely states 'check health' without explaining what health means, which services are checked, whether it's read-only, or any side effects. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is nearly a tautology of the tool name. It does not provide additional structure or information beyond the name, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no parameters. The description does not explain what the tool returns (e.g., status codes, JSON structure) or any context about how the health check works. It is incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so baseline is 4. However, the description only adds minor clarification over the name (adding 'all services'), so it does not significantly enhance semantic understanding. Score 3 reflects adequate but not exceptional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks health of all Supabase services, which is a specific verb+resource. It distinguishes from sibling tools that perform other operations like deploy, delete, or execute SQL, but it doesn't explicitly differentiate from similar diagnostic tools (e.g., supabase_status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as other health-check or status tools in the sibling list. It doesn't mention prerequisites, caveats, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a migration with both up and down SQL for safe rollbacks
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Migration name | |
| up_sql | Yes | SQL to apply the migration | |
| down_sql | Yes | SQL to rollback the migration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears the full burden. It mentions 'safe rollbacks' but does not disclose how the migration is stored, whether it writes to the filesystem, or if it requires a database connection. Key behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly conveys the tool's purpose without any unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the basic action for a simple tool with three string parameters, but lacks context about the lifecycle (e.g., that it creates a local file) and how it fits with other migration tools, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the parameter names and schema descriptions; it simply restates that both up and down SQL are included.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('migration') and clarifies it includes both up and down SQL for safe rollbacks, which distinguishes it from sibling tools like supabase_migration_new that may only create a boilerplate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as deploy_migration or rollback_migration. The description does not mention prerequisites or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new storage bucket
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Bucket ID | |
| public | No | Make bucket public | |
| file_size_limit | No | Max file size in bytes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Create', implying mutation, but does not explain side effects (e.g., if bucket already exists), authentication needs, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and fails to provide important context. It could benefit from a bit more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 3 parameters and no output schema or annotations, the description is minimal. It does not explain the return value, permission requirements, or behavior on failure, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the three parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Create a new storage bucket'), which is distinct from sibling tools like 'delete_storage_bucket' and 'list_storage_buckets'. However, it lacks specificity about the context (e.g., Supabase), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 preconditions, restrictions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an edge function
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Function name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description bears full burden. Only states 'Delete' without disclosing destructiveness, reversibility, or any side effects. Minimal behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, but overly brief. Could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool but misses context: no output description, no error behavior, no prerequisites. Minimal completeness for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 param with description 'Function name'). Description adds no extra meaning beyond schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb and resource clearly: 'Delete an edge function'. It's specific, but does not differentiate from sibling tools like 'deploy_edge_function' or 'invoke_edge_function'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool. No prerequisites, conditions, or alternatives mentioned. Agent lacks context for selecting this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a storage bucket
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Bucket ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. Only 'delete' indicates destruction, but no details on irreversibility, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no repetition. While sparse, it fits the simple tool; could add a note on irreversibility without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description is minimally adequate but lacks any mention of implications like bucket emptiness requirement or deletion confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear 'Bucket ID' description. The tool description adds no extra meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a storage bucket' clearly states the verb and resource, distinguishing it from siblings like create_storage_bucket and list_storage_buckets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, or any prerequisites or safety considerations. The agent gets no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy a Coolify application
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Application UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description simply says 'Deploy a Coolify application' without explaining whether the deployment is asynchronous, idempotent, or what triggers it. Completely insufficient behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but at the cost of informativeness. It is a single generic sentence that does not earn its place; it provides minimal guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and many similar siblings, the description is severely incomplete. It does not explain the deployment process, prerequisites, or return behavior. Substantial gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter with description 'Application UUID'). The description does not mention the parameter or add any meaning beyond the schema. Baseline 3 is inappropriate because the description adds zero value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states action (deploy) and resource (Coolify application). However, it lacks specificity to distinguish from siblings like 'start_coolify_application' or 'restart_coolify_application', which could be confused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, when should an agent use 'deploy' instead of 'start' or 'restart'? Missing exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy a new edge function
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Function name | |
| code | Yes | Function code | |
| verify_jwt | No | Verify JWT tokens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits, but it only states the action. It does not clarify whether the deployment overwrites an existing function, requires authentication, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but given the tool's complexity (3 parameters, no output schema), more detail could be useful. It is minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context such as return values, side effects, or typical usage. For a deployment tool, users need to know if it creates or updates, and what happens to existing functions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the schema already explains each parameter. The description adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'deploy' and the resource 'new edge function', making the primary purpose obvious. However, it does not differentiate from a sibling tool 'supabase_functions_deploy', which appears to perform a similar action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, constraints, or scenarios where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy a new database migration. NOTE: For self-hosted Supabase, consider using supabase_migration_new + supabase_db_push instead for better reliability.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL migration code | |
| name | Yes | Migration name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Deploy a new database migration' without explaining what 'deploy' entails (e.g., immediate effect, destructive nature, permissions needed). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, one of which is a helpful note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 provides basic purpose and a usage note, but it lacks behavioral details, return value info, or prerequisites. It's minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both parameters have descriptions. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Deploy a new database migration.' It uses a specific verb and resource, and distinguishes itself from siblings by mentioning alternative tools for self-hosted Supabase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific guidance: for self-hosted Supabase, to use supabase_migration_new + supabase_db_push instead. This tells the agent when not to use this tool. However, it doesn't elaborate on when exactly to use this tool or compare with other siblings like rollback_migration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy a complete Supabase instance on Coolify
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Deployment name | |
| config | No | Deployment configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Deploy' without disclosing side effects (e.g., overwriting existing instances, required permissions). No mention of destructive or non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core purpose. It earns its place by stating the action and target, though it could add more value without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description omits crucial details like what the config object expects, prerequisites (e.g., Coolify setup, Supabase CLI), and post-deployment behavior. Incomplete given tool complexity and number of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context that the tool deploys a 'complete Supabase instance', which implies config should contain Supabase-specific settings, but does not elaborate on config structure beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Deploy a complete Supabase instance on Coolify', providing a clear verb and resource. It distinguishes from sibling tools like deploy_coolify_application (generic app) and deploy_edge_function, but could be more specific about what a 'complete Supabase instance' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling deployment tools (e.g., deploy_coolify_application, deploy_migration). Does not mention prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute raw SQL query on Supabase database. NOTE: For self-hosted Supabase, use supabase_cli_execute with "db execute" for better reliability.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. While it mentions executing raw SQL, it does not disclose potential destructive side effects (e.g., DROP TABLE), required permissions, or whether the action is reversible. The description adds minimal behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff: first sentence states purpose, second provides usage guidance. Front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the tool returns (e.g., result set, affected rows, or status). For a raw SQL execution tool, this is a significant gap that leaves the agent uncertain about the response format or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a description for the single 'sql' parameter ('SQL query to execute'). The tool description does not add any extra meaning or usage hints beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute raw SQL query on Supabase database', which is a specific verb+resource pair. It also differentiates from sibling supabase_cli_execute by noting a self-hosted alternative, ensuring the agent can distinguish between similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use this tool: 'For self-hosted Supabase, use supabase_cli_execute with "db execute" for better reliability.' This provides clear guidance on when to choose an alternative, fulfilling the guidelines dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get authentication configuration
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as whether it is read-only or any side effects. For a tool with no annotations, the description carries the burden but fails to disclose even basic safety info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is appropriately short for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no params, no output schema), the description is adequate but could be improved by hinting at the return value or scope of configuration. Minimal but not incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100% (empty schema). The description does not need to explain parameters, and no additional param info is required, so baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get authentication configuration' clearly states the action (get) and the resource (authentication configuration), distinguishing it from sibling tools like update_auth_config (write) and get_realtime_config (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, but the simple read operation implies it's for retrieving auth config. Without exclusions or context, the usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific Coolify application
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Application UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states 'Get details' without mentioning whether the operation is read-only, requires authentication, or has any side effects. For a read tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is well-structured and front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate but lacks information on return values or behavioral traits. It covers the basic purpose but could be more complete by hinting at the output contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. The schema already documents the 'uuid' parameter with its description. With 100% schema coverage, the description does not compensate or elaborate on the parameter's context, such as how to obtain the UUID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('details of a specific Coolify application'), differentiating it from sibling tools targeting other resources like databases or services. However, it could be more specific about what 'details' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., list_coolify_applications for listing all, or get_coolify_database for other resources). The description solely states functionality without contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute get_coolify_database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, required permissions, side effects, or response format. The description carries the full burden but offers nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but vacuously repeats the tool name. It lacks substance and does not efficiently convey any useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling tools and the absence of output schema, the description is utterly incomplete. It does not explain how to identify a specific database, what the output looks like, or any operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters with 100% coverage, but the description adds no meaning beyond the schema. It does not clarify what 'execute' entails or what the tool returns, making it unhelpful despite schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute get_coolify_database' is a tautology, restating the tool name without indicating what specific action it performs. It fails to distinguish from sibling tools like 'list_coolify_databases' or 'get_coolify_application'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'list_coolify_databases' (to list all databases) or other get tools. No context on prerequisites or required identifiers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get application logs from Coolify
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Application UUID | |
| lines | No | Number of log lines |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does not mention if logs are real-time, cached, paginated, or how errors (e.g., invalid UUID) are handled, which is insufficient for a retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no superfluous information. Efficiently communicates the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple log retrieval tool with two parameters, the description is minimally adequate. However, it lacks details on output format, error scenarios, and how it differs from similar tools, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The tool description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (application logs) and source (Coolify). However, it does not differentiate from sibling log-related tools like 'get_edge_function_logs', leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of prerequisites, limitations, or comparisons to other log tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific Coolify service
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Service UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but only states the basic purpose. It fails to disclose what happens if the UUID is invalid, whether the operation is read-only, or any permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one short sentence—with zero wasted words. It achieves its purpose without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema), the description is adequate but incomplete; it doesn't hint at what 'details' are returned (e.g., status, configuration), which would help an agent anticipate the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no extra meaning beyond the input schema's parameter description. With 100% schema coverage, a baseline of 3 is appropriate as the schema already defines 'uuid' as 'Service UUID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'details of a specific Coolify service', making the action unmistakable. It distinguishes itself from siblings like list_coolify_services (lists all) and action-oriented tools like start/stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need details of a single service but does not explicitly state when to use this tool over alternatives (e.g., list_coolify_services) or provide any usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status of Supabase deployment on Coolify
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Application UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose whether the operation is read-only, requires authentication, or has any side effects. For a status check, it is likely safe, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and efficient. However, it could be expanded slightly to include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description is minimal. It lacks information about the return format, possible status values, or error conditions, making it incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter 'uuid' with description 'Application UUID'). The description adds no further meaning beyond the schema, meeting the baseline but not compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get' and resource 'status of Supabase deployment on Coolify', distinguishing it from siblings like 'get_coolify_application' which is more general. It 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus alternative tools (e.g., get_coolify_application, deploy_supabase_to_coolify). No context on prerequisites or typical use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs for an edge function
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Function name | |
| limit | No | Number of log entries |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'Get logs', without explaining whether it returns live or historical logs, pagination, rate limits, or any side effects. The read-only nature is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, very concise. No unnecessary words. However, it could be slightly expanded (e.g., one more sentence on usage) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is too minimal. It does not specify return format (e.g., array of log objects), whether logs are real-time or historical, or any filtering beyond 'limit'. An agent needs more context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for both parameters. The description adds no additional context beyond the schema. Baseline 3 is appropriate as schema handles documentation, but no extra value from description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get logs for an edge function', specifying the action (get logs) and resource (edge function). This distinguishes it from sibling tools like 'list_edge_functions' (list functions) and 'invoke_edge_function' (invoke function).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. No mention of prerequisites, limitations, or scenarios where another tool might be better. For example, it does not advise checking if the function exists first or differentiate from 'invoke_edge_function'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status of a specific migration
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | Migration version |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'get status'. It does not disclose the response format, whether the operation is read-only (implied but not stated), or any side effects. For a tool with no annotations, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. While it could be expanded with more context, it achieves efficient communication without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description fails to explain what the status response contains (e.g., fields, possible values). It also lacks context about the migration system (e.g., Supabase). This is incomplete for a tool with zero additional structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the sole parameter 'version' has a description. The description adds no extra meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get status of a specific migration', with a specific verb 'Get' and resource 'status of a specific migration'. This distinguishes it from sibling tools like list_migrations (lists all) and rollback_migration (changes state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention when to check migration status, prerequisites, or contrast with siblings like list_migrations or get_deployment_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute get_realtime_config
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description gives no behavioral information such as idempotency, side effects, or authorization requirements. The word 'get' implies a read operation, but this is not confirmed, and no other traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks substance; it is under-specification rather than conciseness. A single sentence repeating the function name does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameter info, and a one-word description, the tool is completely opaque. The agent cannot determine its purpose, behavior, or appropriate context, making it nearly unusable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The description does not need to add parameter meaning, but it also fails to explain what the tool returns or how to interpret its output. A baseline of 4 is reduced due to lack of any added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute get_realtime_config' is a tautology, restating the tool name without specifying what a realtime config is or what the tool actually does. It fails to distinguish from sibling tools like get_auth_config or get_supabase_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Supabase version information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the purpose but does not disclose behavioral traits like authentication requirements, rate limits, or potential side effects. For a read-only operation, the description should at least indicate that it is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word is necessary; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what information is returned (e.g., version string, JSON object). It does not, leaving ambiguity. For a simple tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema coverage is 100%. The description correctly implies no input is needed. According to guidelines, 0 parameters yields a baseline of 4, and the description adds no contradictory or missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get Supabase version information'. It uses a specific verb and resource, and distinguishes itself from sibling tools like 'supabase_status' which likely provides more comprehensive status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_status'. The description does not mention prerequisites, 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.
Invoke an edge function
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Function name | |
| payload | No | Function payload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose invocation side effects, return value, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, but too minimal for a tool with nested parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no hints about return value; missing context on authentication, error handling, and payload format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions; description adds no additional meaning, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'invoke' and resource 'edge function', clearly distinguishing from sibling tools like deploy_edge_function or delete_edge_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, its prerequisites, or when to choose alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Coolify applications
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states the basic operation, omitting details like authentication, pagination, ordering, or effect scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of three words, perfectly concise and front-loaded with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what information is returned (e.g., fields, format). For a simple list, this is insufficient for an agent to fully understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters with 100% coverage, so baseline is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all Coolify applications' with a specific verb and resource. It distinguishes from sibling tools like list_coolify_databases and list_coolify_services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus other listing tools or get_coolify_application. Usage is implied but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute list_coolify_databases
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a description that only states 'Execute', there is no disclosure of behavioral traits such as read-only nature, authentication requirements, or potential side effects. The AI agent has no information about the tool's safety or expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise but adds no value, essentially repeating the tool name. It is under-specification rather than effective conciseness, as it fails to provide any useful information in its single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters), the description is still incomplete. It does not mention what the tool returns (e.g., a list of databases) or any context such as that it requires no arguments. The presence of many sibling list tools makes this omission more significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema coverage is 100% (trivially). With 0 parameters, the baseline is 4, and the description, while minimal, does not need to add parameter-level meaning. However, it could still benefit from context about the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute list_coolify_databases' is essentially a tautology of the tool name, providing no additional clarity. It fails to specify that the tool lists databases from Coolify or to distinguish it from sibling list tools like list_coolify_applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as list_coolify_applications or list_coolify_services, which are similar list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Coolify services
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'List all Coolify services,' offering no details about read-only behavior, side effects, authentication, or rate limits. The read-only nature is implied but not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero waste. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-less list tool, the description is adequate but minimal. It doesn't explain what constitutes a 'service' or provide return format, and no output schema exists. Sibling tools indicate a richer ecosystem, so more context could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema description coverage is 100%. The description adds no parameter info because none exists, which is appropriate. Baseline 4 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all Coolify services'. The name itself is specific, and it distinguishes from sibling tools like list_coolify_applications and list_coolify_databases by the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives such as list_coolify_service (singular) or other listing tools. The context implies it's for listing services, but no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all deployed edge functions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the function. It does not disclose what the response contains (e.g., function names, metadata) or any behavioral traits like pagination or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and contains 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and sibling tools that likely provide richer results (e.g., get_edge_function_logs), the description is too minimalist. It omits what information the list returns, which an agent would need to decide between this and other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The description adds meaning by clarifying the scope ('all deployed edge functions'), but no parameter-specific details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all deployed edge functions' is specific with a clear verb ('list') and resource ('deployed edge functions'). It distinguishes itself from sibling tools like invoke, delete, deploy, and get logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied but lacks exclusions or contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all database migrations with their status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation without side effects, but no explicit behavioral traits are disclosed. Since annotations are absent, this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and front-loaded. Could be slightly more informative about what 'status' entails.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details about authentication, return format, or integration with other tools. Without output schema, the description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined, so the description adds no parameter detail. With 0 parameters, baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all database migrations with their status. However, it does not differentiate from sibling tools like 'get_migration_status' or 'supabase_migration_list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_migration_status' or 'supabase_migration_list'. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all storage buckets
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the action. For example, it does not mention authentication requirements, scope of listing (e.g., all projects or current project), or whether it returns full bucket objects or just names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is acceptable but could be improved by specifying the scope or return format. It provides minimal context beyond the tool's basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the input schema coverage is trivially 100%. The description adds no additional parameter information beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all storage buckets' clearly states the action (list) and resource (storage buckets). It is specific and distinct from sibling tools like create_storage_bucket and delete_storage_bucket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (whenever a list of buckets is needed), but provides no explicit guidance on when not to use or alternatives. Since there are no sibling list tools, usage is straightforward, but lack of exclusionary info keeps it at 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart a Coolify application
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Application UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states action without disclosing side effects, permissions, or async behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal but adequate for a simple restart action; lacks detail on return values or synchronization.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage but the description adds no extra meaning beyond 'Application UUID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (restart) and resource (Coolify application), distinguishing it from siblings like start and stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use restart vs alternatives, no prerequisites or effects mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rollback the last N migrations
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of migrations to rollback |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It fails to mention the destructive nature, any irreversible effects, or required permissions, leaving the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and lacks structure. While concise, it omits necessary details, making it less useful than a slightly longer but more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain return values or error conditions. For a rollback operation, this incompleteness hampers correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the 'count' parameter with a default. The description adds no extra meaning, meeting the baseline for 100% coverage but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action (rollback) and resource (last N migrations), but does not distinguish it from sibling tools like rollback_migration or rollback_to_version, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any prerequisites, which is insufficient given the abundance of similar migration rollback tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rollback a specific migration (optionally with down SQL)
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | Migration version to rollback | |
| down_sql | No | SQL to execute for rollback (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose destructive nature, permission requirements, or side effects beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema descriptions and no output schema, the description is adequate but lacks additional context about destructive behavior or rollback scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already described. The description adds minimal extra meaning beyond 'optionally with down SQL' which is also evident from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Rollback') and the resource ('specific migration'), and distinguishes it from siblings like rollback_last_migrations or rollback_to_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 rollback_last_migrations or rollback_to_version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rollback a migration using its stored down SQL
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | Migration version |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'rollback' and 'using stored down SQL', which implies a destructive operation but does not state whether rollback is reversible, what happens to existing data, or any side effects. Important behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy. It is front-loaded and communicates the core purpose efficiently. However, it might benefit from slight expansion for context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's potential impact (database migration rollback), the description is inadequate. It does not clarify what 'down SQL' entails, what the return value is (no output schema), or any success/failure indicators. The context signals show a simple schema, but the description should still provide more operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter with a description ('Migration version'). The tool description does not add any new meaning beyond what the schema already provides. Per guidelines, baseline 3 is appropriate when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rollback), the resource (migration), and the specific method (using stored down SQL). It effectively distinguishes this tool from siblings like 'rollback_migration' or 'rollback_to_version' by highlighting the use of stored down SQL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. It lacks information on prerequisites (e.g., migration must have down SQL stored), when not to use it, or any conditions. The sibling tools suggest different rollback methods, but the description does not clarify the appropriate context for this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rollback all migrations after a specific version
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes | Target version to rollback to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only implies destructive action without detailing side effects, confirmation requirements, or data impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded, but could benefit from minor restructuring to include usage hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a destructive operation; lacks return value, error scenarios, preconditions, or additional context given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a parameter description; tool description restates the concept but doesn't add new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (rollback), resource (all migrations), and scope (after a specific version), distinguishing it from siblings like rollback_last_migrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like rollback_last_migrations or rollback_migration; no context on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a Coolify application
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Application UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral context. It fails to disclose any behavioral traits, such as whether the action is idempotent, if prerequisites are needed, or what the start operation entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, but at the expense of completeness. It lacks structured information to support effective tool use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is incomplete. No output schema exists, so the description should at least hint at what happens after starting. It fails to provide sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the uuid parameter as 'Application UUID' (100% coverage). The description adds no additional meaning, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a Coolify application' clearly states the action and resource, but lacks distinction from sibling tools like deploy_coolify_application or restart_coolify_application. It is merely adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as deploy_coolify_application or restart_coolify_application. There are no when-not or usage context hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a Coolify service
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Service UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only states 'Start'. It does not explain whether the operation is idempotent, what happens if the service is already started, required permissions, or side effects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), but it lacks structure and does not earn its place by adding significant value over the tool name. It could be improved with a brief note on behavior or context without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation operation with no output schema and sparse description, more information is needed to understand its effects. The presence of many sibling tools heightens the need for contextual completeness, which is lacking here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'uuid' parameter, and the description does not add any additional meaning beyond the schema. Baseline score of 3 is appropriate since the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a Coolify service' clearly indicates the tool starts a service, but it lacks specificity about what constitutes a 'Coolify service' versus sibling tools like 'start_coolify_application', which could cause confusion. The purpose is vague and does not differentiate from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives like 'start_coolify_application' or prerequisites (e.g., service must exist, not already running). The agent receives no contextual guidance for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a Coolify application
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Application UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral details such as what happens to the stopped application (e.g., data preservation, ability to restart), required permissions, or irreversible consequences. It only states 'stop', lacking such transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous information. It is appropriately concise for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop operation with no output schema, the description is adequate but could mention that the application must be running or that stopping is reversible. The minimal context provided meets basic needs but lacks completeness for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, and the tool description adds no further semantic value to the parameter 'uuid'. Baseline 3 is appropriate since the schema already explains the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Stop' and the resource 'Coolify application', making the tool's purpose immediately understandable. It distinguishes from siblings like start_coolify_application or restart_coolify_application by using a distinct verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 restart_coolify_application or stop_coolify_service. The description does not mention prerequisites, side effects, or preferability conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a Coolify service
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Service UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear full burden. It does not disclose side effects (e.g., service downtime, data loss requirements), whether it is graceful or forceful, or any required permissions. Only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, but slightly under-specified given the action's potential impact. Still, it is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a state-changing operation with one required parameter and no output schema, the description lacks crucial context about effects, error cases, or return values. Incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter 'uuid' described as 'Service UUID'). The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop a Coolify service' states the action (stop) and resource (service) clearly. The name itself distinguishes it from sibling 'stop_coolify_application', though the description does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 other stop tools (e.g., stop_coolify_application) or alternatives. No context about prerequisites or post-conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute arbitrary Supabase CLI command
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | CLI command (without "supabase" prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose potential behavioral traits such as destructive capabilities, authorization requirements, or output characteristics. For a tool that executes arbitrary commands, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but given the tool's power, a bit more detail could be added without sacrificing conciseness. Still, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should compensate with context about invocation, safety, and output. It fails to mention prerequisites, error handling, or security considerations, making it incomplete for a tool that executes arbitrary commands.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter 'command' with a description. The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute arbitrary Supabase CLI command' clearly states the action and resource. It distinguishes itself from sibling tools by indicating 'arbitrary', meaning it can run any CLI command not covered by specific tools. However, it could be more explicit about its role as a fallback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the many sibling tools that handle specific operations. Without this, an agent might overuse it, risking unintended side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate migration from database schema changes
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Migration name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention side effects, requirements (e.g., a linked Supabase project), or whether it alters the database. The description is overly minimal for a migration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words), but it lacks structure and does not earn its place by adding value beyond the tool name. It is not poorly written, but under-specification reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (generating a migration from schema changes) and the absence of an output schema, the description should explain the process, prerequisites, or output format. It fails to provide sufficient context for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage (one parameter with description 'Migration name'). The description adds no further meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a migration from database schema changes, using a specific verb and resource. However, it does not differentiate from sibling migration tools like create_migration_with_rollback or supabase_migration_new, which could confuse selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With many sibling migration tools (e.g., create_migration_with_rollback, supabase_migration_new, deploy_migration), the lack of context reduces usability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push local migrations to remote database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects (e.g., potential overwriting, need for linking, safety) or behavioral traits beyond the basic action. Minimal transparency for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no fluff. Fully front-loaded, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter tool with no output schema, but lacks behavioral context. Given sibling migration tools, more guidance on consequences or prerequisites would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters. Schema coverage is 100% trivially. The description adds no parameter info, but baseline for 0 params is 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Push local migrations to remote database' uses specific verbs and resources, clearly distinguishing from sibling tools like deploy_migration, rollback_migration, or supabase_db_diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., deploy_migration or supabase_db_reset). The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset local database to initial state
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose that resetting is destructive and irreversible. 'Reset local database to initial state' implies data loss, but does not explicitly state the behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (5 words), no filler. Appropriate for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, so the description should clarify what 'initial state' means (e.g., schema only, seed data, or empty). It also lacks safety warnings for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, baseline is 4. No additional info is needed beyond the schema, which fully covers the parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reset) and resource (local database) and outcome (to initial state). It provides a specific verb and resource, but does not differentiate from siblings like rollback or deploy migration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like 'rollback_last_migrations' or 'supabase_db_push'. The description omits that it is destructive and intended for local development only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy edge functions using Supabase CLI
| Name | Required | Description | Default |
|---|---|---|---|
| function_name | No | Function name (optional, deploys all if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'deploy edge functions', which implies a write operation but does not explain side effects, idempotency, or error behavior. The transparency is insufficient for a deployment action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that covers the core purpose. No wasted words, but could be slightly more structured with key behavioral notes. Still earns a high score for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is somewhat complete. However, it lacks context about tool prerequisites, response details, and how it differs from similar tools. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the parameter 'function_name' is fully described in the schema. The tool description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deploy), resource (edge functions), and method (using Supabase CLI). However, it does not differentiate from the sibling tool 'deploy_edge_function', which may have a similar purpose. The specificity is good but lacks distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'deploy_edge_function'. No mention of prerequisites such as requiring the CLI to be installed (check_cli_installed exists). The usage context is entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Serve edge functions locally
| Name | Required | Description | Default |
|---|---|---|---|
| function_name | No | Function name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'serve locally' without explaining that it starts a local server, whether it blocks, what port it uses, or dependencies. Behavioral traits are opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words), but conciseness should not sacrifice necessary information. It is front-loaded but lacks structure; it's a bare statement without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 optional parameter, no output schema, and no annotations, the description is incomplete. It does not mention how to stop the server, if it's a blocking call, or that it requires Supabase CLI. It leaves many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the parameter 'function_name' is described as optional). The tool description adds no additional meaning beyond the schema. Baseline 3 is appropriate as it does not hinder but does not enhance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Serve edge functions locally' clearly states the verb (serve) and resource (edge functions), and it distinguishes from sibling tools like deploy or invoke. However, it could be more specific about scope (e.g., serves a specific function or all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 invoke_edge_function or deploy_edge_function. The description lacks context about local development workflow or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate TypeScript types from database schema
| Name | Required | Description | Default |
|---|---|---|---|
| output | No | Output file path | types/supabase.ts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states the outcome ('generate types') without explaining side effects (e.g., file overwriting, network calls, authentication requirements, or whether it connects to a remote database). This is insufficient for an agent to assess safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous information. It is front-loaded with the core action. Could be improved by adding a brief usage note, but for its length, it is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (1 optional param, no nested objects, no output schema), the description could be more complete. It fails to explain the context (e.g., requires a linked Supabase project, generates types based on local schema if supabase start is running, or reads from remote). The agent is left with significant unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 parameter with full description). The description adds no extra meaning beyond the schema; it merely restates the tool's purpose. Baseline score of 3 is appropriate since the schema already documents the parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('generate') and the resource ('TypeScript types from database schema'). It distinguishes the tool from siblings, none of which mention type generation. However, it could be more specific about the scope (e.g., for the linked Supabase project).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description does not mention prerequisites (e.g., a linked project), typical workflow position (e.g., after schema changes), or when not to use it (e.g., if types are already up-to-date). The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a new Supabase project
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Project path | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It merely states 'Initialize' without explaining side effects (e.g., file creation, configuration changes, API calls), required permissions, or irreversible actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy or superfluous information. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (one parameter, no output schema), the description lacks essential context: what 'initialize' entails (e.g., project scaffolding, configuration setup), potential prerequisites, and any notable side effects. An agent would need additional knowledge to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter with 100% description coverage, providing 'Project path' and default value. The tool description adds no further semantic context, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Initialize a new Supabase project' clearly states the tool's purpose with a specific verb and resource. It distinguishes from siblings like supabase_link or supabase_start, which have different actions, though it could further clarify whether this is local or remote initialization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, typical usage context, or exclusions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link to a remote Supabase project
| Name | Required | Description | Default |
|---|---|---|---|
| project_ref | Yes | Project reference ID | |
| password | No | Database password (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only says 'link to a remote Supabase project', offering no behavioral details like effects on local config, authentication requirements, or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no unnecessary words, but it is almost too brief. A slightly longer description could improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a linking operation with no output schema and no annotations, the description fails to cover important context such as expected outcomes, side effects, or authentication steps, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (project_ref, password) with 100% coverage. The description adds no extra meaning beyond the schema, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Link to a remote Supabase project' clearly states the action and resource, distinguishing it from sibling tools like supabase_init or supabase_start. However, it is brief and does not elaborate on the nature of linking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites or contexts where linking is appropriate. The description lacks any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all migrations (CLI)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'List all migrations (CLI)', which implies a read-only operation but does not explicitly state that it is non-destructive or disclose any behavioral traits such as network calls or data source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (3 words), which is concise, but it sacrifices necessary detail. It could include a sentence about the output or context without becoming verbose. The dimension rewards front-loading, but here it is too sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a minimal description, the tool is incomplete. It does not explain what 'migrations' refers to, what the list contains, or how it differs from the sibling 'list_migrations' tool. The agent has insufficient information to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no need to describe parameters. The description adds no parameter information, but that is acceptable given the schema. Baseline score of 4 for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all migrations (CLI)', which indicates the verb and resource, but it does not differentiate from the sibling tool 'list_migrations' that likely serves a similar purpose. The addition of '(CLI)' hints at context but is insufficient for clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'list_migrations' or other migration-related tools. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new migration file
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Migration name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states a basic action ('Create'). It fails to disclose side effects such as file creation on disk, potential overwrite behavior, or dependencies on the Supabase CLI. For a writing operation, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and thus concise, but it is overly minimal. It omits useful information that would justify its length, earning an average score for being neither verbose nor informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 parameter, no output schema, no annotations), the description should still provide context like expected output (e.g., file path) or CLI requirements. It fails to complete the picture, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a 'name' parameter with description 'Migration name', achieving 100% coverage. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new migration file', distinguishing it from sibling tools like create_migration_with_rollback. However, it does not specify the context (e.g., using Supabase CLI) or the file's location, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as create_migration_with_rollback. The description lacks any context about prerequisites or typical use cases, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repair migration history
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. 'Repair' implies state mutation (likely destructive), but no details are given about side effects, required permissions, or whether changes are reversible. The description is opaque, scoring 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words), but it sacrifices clarity. It earns its place as a brief statement but fails to provide enough context for a tool that likely modifies state. A score of 3 reflects reasonable brevity with insufficient substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a vague name, the description is incomplete. It does not explain what 'repair' entails, how it differs from rollback, or what the outcome is. For a tool with potential destructive impact, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters (100% coverage), so baseline is 4. The description adds no parameter info, but there is nothing to add. It could hint at how the tool works without params, but it's acceptable given no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Repair migration history' identifies a verb and resource, indicating the tool is for fixing migration history. However, it is vague: 'repair' could mean multiple actions (e.g., reapply, skip, reset), and it does not distinguish from sibling tools like rollback_migration or deploy_migration. A score of 3 reflects adequate but ambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Sibling tools include rollback, deploy, and list migrations, but the description offers no context for when 'repair' is appropriate. This leaves the agent without decision clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start local Supabase development environment
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose what happens when the tool is invoked (e.g., starts Docker containers, initializes services, logs output). The agent has no information about side effects, required permissions, or expected behavior beyond the minimal verb 'start'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loades the key action and resource. While very brief, it does not contain any fluff, but could be slightly improved by adding a little more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters, the tool's action (starting a local Supabase environment) is complex. The description omits details about what exactly is started, what the prerequisites are, how to verify success, or any output it produces. This is insufficient for an agent to understand the full implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds no parameter-specific information, but none is needed since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Start) and the resource (local Supabase development environment), which is specific and unambiguous. It distinguishes itself from sibling tools like supabase_init or supabase_status by focusing on starting the environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like supabase_init (for initialization) or supabase_start vs. start_coolify_application. Missing context about prerequisites (e.g., Docker running, Supabase CLI installed) or when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status of local Supabase services
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get status', implying a read operation, but lacks details on whether it affects services, requires prerequisites, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. Every word contributes to the purpose, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is minimal. It tells what the tool does but not the format or content of the status, nor any edge cases. For a simple tool this may suffice, but more context could help in the ecosystem of many Supabase tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema covers 100%. The description does not need to add parameter info since there are none. It appropriately indicates that no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'status of local Supabase services', clearly stating the tool's action. It implicitly distinguishes from sibling 'check_supabase_health' by specifying 'local', but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'check_supabase_health' or 'supabase_start'. There are no exclusions or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop local Supabase development environment
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'stop' without detailing what happens to the environment, whether data is lost, or if the tool is safe to use mid-operation. This misses an opportunity to clarify the destructive or safe nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, direct sentence with no extraneous words. Every part serves the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop command with no parameters or output schema, the description is functional but lacks behavioral details that would aid an AI agent (e.g., confirmation of success or effects on running processes).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, but none is needed. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Stop), the resource (local Supabase development environment), and distinguishes from sibling tools like supabase_start and supabase_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., stop_coolify_application) or prerequisites. The description implies usage but does not exclude other stop scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update authentication configuration
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | Auth configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details such as side effects, authentication requirements, or idempotency. This is a critical gap for a configuration mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 4 words, but this brevity sacrifices informativeness. It is not front-loaded with critical details; however, it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a nested input with poor description, the description is severely incomplete. It lacks details on return values, error states, or expected behavior, making it insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the parameter description 'Auth configuration' adds minimal meaning. The tool description does not elaborate on the structure or accepted fields of the 'config' object, leaving the agent with very little guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action and resource ('Update authentication configuration'), which is clear but adds no detail beyond the tool name. It distinguishes from sibling 'get_auth_config' but is vague about what aspects are updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites or context provided. The description does not mention any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update application environment variables
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Application UUID | |
| env | Yes | Environment variables |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only says 'Update', implying mutation, but does not specify whether variables are replaced or merged, any idempotency, or side effects. This lack of detail is insufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action. It earns its place but sacrifices behavioral detail for brevity. Could be slightly more structured without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has a nested object parameter (env) and no output schema, the description should provide more context on the update behavior (e.g., merge vs overwrite, side effects). The current one-sentence description is too minimal to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters. The description adds no additional meaning beyond summarizing the schema, meeting the baseline expectation. No extra constraints or formats are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and resource (application environment variables), which is specific and matches the tool's function. However, it does not differentiate from other update tools on the server, such as update_auth_config, limiting its clarity in distinguishing when to use it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over alternatives, nor does it mention any prerequisites or conditions. The agent is left without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Supabase deployment
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Application UUID | |
| config | Yes | Updated configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects, required permissions, or consequences of updating an existing deployment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence, no extraneous words. However, it lacks structure like bullet points or examples that could enhance usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no output schema, the description is too minimal. It fails to explain return values, error handling, or prerequisites like needing a valid UUID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it does not explain that 'uuid' identifies the deployment or what structure 'config' expects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing Supabase deployment' clearly states the action (update) and the resource (Supabase deployment). It distinguishes from sibling tools like 'deploy_supabase_to_coolify' which create new deployments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'deploy_supabase_to_coolify' or 'update_auth_config'. The description offers no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify system setup and check health of all services (Coolify, Supabase, CLI)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It implies a read-only health check, but does not explicitly state idempotency, side effects, or what 'health' means. Behavioral traits beyond purpose are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly stating the tool's action and scope. No unnecessary words; front-loaded with the verb 'Verify'. This is ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description covers the core purpose but lacks completeness regarding what the output/return value is (e.g., a status report or a simple boolean). A statement about expected results would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter information, which is fine. According to the calibration, 0 parameters baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to verify system setup and check health of specific services (Coolify, Supabase, CLI). It uses a specific verb ('Verify') and resource ('system setup'), and distinguishes itself from sibling tools like `check_cli_installed` and `check_supabase_health` by being a broader health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 its siblings. There is no mention of prerequisites, contexts, or alternatives. Given the existence of more specific check tools, such guidance would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are generally distinct by domain (Supabase vs Coolify), but overlaps exist: multiple rollback tools (rollback_last_migrations, rollback_migration, rollback_migration_with_down_sql, rollback_to_version) and edge function deployment (deploy_edge_function vs supabase_functions_deploy). Notes like execute_sql suggesting supabase_cli_execute add ambiguity.
Naming is inconsistent: some tools use verb_noun (create_migration_with_rollback), others use supabase_ prefix (supabase_db_diff), and Coolify tools mix verb_coolify_noun (deploy_coolify_application) and get/list variations (get_coolify_database vs list_coolify_databases). No consistent pattern.
56 tools is excessive for a server covering two platforms. Many tools are thin wrappers over CLI commands (supabase_*), leading to redundancy. A more focused set (20-30 tools) would be more manageable.
The tool set covers major workflows: migrations, edge functions, storage, auth, realtime for Supabase, and CRUD for Coolify applications/services. Minor gaps like database backup/restore are present, but overall lifecycle coverage is strong.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage Supabase projects end to end across database, auth, storage, realtime, and migrations. Moni…
Your Supabase account in natural language: run SQL, apply migrations, manage tables, storage, edge f
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Managed database, auth, file storage, email, analytics, and deployment for coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dj-pearson/supabase-coolify-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
