Provides tools for provisioning, querying, and migrating PostgreSQL databases through the LobsterDB managed service.
Click on "Deploy 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., "@lobsterdb create a new database for my project"
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.
MCP server for LobsterDB — managed PostgreSQL for AI agents. Provision databases, run SQL, evolve schemas with tracked migrations. No API keys, no human signup, no configuration.
Add to your MCP config (.mcp.json, claude_desktop_config.json, .cursor/mcp.json, etc.):
{
"mcpServers": {
"lobsterdb": {
"command": "npx",
"args": ["-y", "@lobsterkit/db-mcp@0.1.0"]
}
}
}On first use, an account is created automatically and your token is saved to ~/.lobsterdb/token.
Related MCP server: PostgreSQL MCP
Tool | Description |
| Provision a new Postgres database |
| List all databases on the account |
| Get details and connection string for a database |
| Permanently delete a database |
| Run parameterized SQL — SELECT, INSERT, UPDATE, DELETE. Supports multi-statement SQL (only the last statement's result is returned; intermediate results are discarded). |
| Get table/column schema optimized for LLM context |
| Apply tracked, idempotent DDL migrations |
| Show schema change history |
| Create a v2 DDL-aware point-in-time backup (Builder+) |
| View tier, limits, and usage |
Variable | Description |
| API key (skips auto-signup and file persistence) |
| Custom API base URL (default: |
Website: theclawdepot.com/db
SDK: @lobsterkit/db
API docs: api.theclawdepot.com/db/docs
This MCP server is part of the LobsterKit multi-product ecosystem. Accounts can be linked across LobsterVault, LobsterDB, and LobsterMail using a linkToken at signup, enabling a single Stripe customer and an automatic multi-product discount (see pricing).
MIT
Provision a new PostgreSQL database. Returns a connection string ready to use immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A short, descriptive name for the database (e.g. "pokemon-tracker", "my-agent-db") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the return value ('a connection string ready to use immediately'), but omits permissions required, idempotency/duplicate-name behavior, and whether provisioning is synchronous or billed.
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 short sentences with zero filler; the purpose is front-loaded and the return-value note follows immediately. Nothing could be trimmed without losing 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?
For a one-parameter creation tool with no output schema, the description covers purpose and the returned artifact, which is the key thing an agent needs. It stops short of covering failure modes or naming constraints that a mutating tool would ideally mention.
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 single, well-documented 'name' parameter, so the baseline is 3. The description adds no extra meaning about naming constraints (uniqueness, character limits) beyond the schema example.
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?
States a specific verb ('Provision') and resource ('PostgreSQL database'), which cleanly separates it from delete_database, list_databases, and get_database. It does not explicitly name or contrast with any sibling, so it falls short of the top score.
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?
There is no when-to-use guidance, no prerequisite (e.g. account/plan limits), and no mention of alternatives such as migrate for an existing database. The agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a database and all its data.
| Name | Required | Description | Default |
|---|---|---|---|
| databaseId | Yes | The database ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the two most important traits: the operation is irreversible ('Permanently') and the scope of destruction ('all its data'). However, it is silent on permission/authorization requirements, whether related artifacts (migrations, snapshots) are affected, and how partial failures are handled.
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 front-loaded sentence with no filler; the destructive scope is stated first. It is efficient, though for a high-stakes destructive tool the brevity edges toward under-specification rather than true economy.
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 one-parameter destructive tool with no annotations and no output schema, the description minimally covers what is destroyed but omits reversibility caveats beyond 'permanently', authorization needs, and failure behavior. Adequate as a minimum, but thin for an irreversible 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 description coverage is 100% and the single parameter (databaseId) is fully documented in the schema as the database ID to delete, so the description adds no parameter detail. Baseline 3 applies when the schema already does the work.
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?
States a specific verb (delete) and resource (database) plus the blast radius (all its data), which cleanly separates it from siblings like create_database, get_database, and list_databases. It stops short of explicitly naming or contrasting an alternative tool, so sibling differentiation is implied rather than stated.
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?
There is no guidance on when to use this versus alternatives such as snapshot, migrate, or introspect_schema, and no prerequisites or preconditions (backup first, ownership, confirmation) are mentioned. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your account tier, usage, and limits.
| 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 burden; 'Get' implies a safe read with no mutation, which is the main behavioral fact for this tool. It does not disclose auth requirements, rate limits, or whether the response is account-scoped versus user-scoped.
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 short front-loaded sentence that lists the returned content in order of relevance. 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?
With no output schema and no annotations, the description is the only source of return-value information, and 'tier, usage, and limits' is only a sketch of the response shape. For a simple zero-param read tool this is nearly adequate but leaves format and scope unspecified.
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?
Zero parameters, so the schema has nothing to document and there is no semantic gap to fill. 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?
States a specific verb (Get) and resource (account) and enumerates the returned fields (tier, usage, limits), which clearly separates it from the database-oriented siblings. It does not explicitly name a sibling, but the resource scope makes the distinction obvious.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_database. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific database including its connection string.
| Name | Required | Description | Default |
|---|---|---|---|
| databaseId | Yes | The database ID (e.g. db_...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that the result includes a connection string, which is a useful behavioral trait (sensitive data exposure) and implies a read operation. However, it says nothing about authentication requirements, error behavior, or whether the connection string is always returned.
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, front-loaded sentence with no filler. Every word contributes to the purpose and the key return detail.
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 single-parameter read tool with full schema coverage, the description covers the essential return value (connection string) despite having no output schema. However, it omits usage alternatives and behavioral details such as auth or error handling, leaving it 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%, so the single databaseId parameter is already fully documented in the schema. The description adds no syntax, format, or example details beyond what the schema provides, making the baseline score of 3 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 states a specific verb ('Get') and resource ('database'), and adds a distinguishing detail ('including its connection string'). An agent can easily separate this from list_databases, create_database, delete_database, and other siblings without opening the schema.
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 phrase 'for a specific database' implies the tool is used when a single databaseId is known, but there is no explicit when-to-use, when-not-to-use, or alternative routing (e.g., list_databases vs get_database). Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the database schema — tables and columns — in a format optimized for LLM context. Use this before writing queries against an existing database.
| Name | Required | Description | Default |
|---|---|---|---|
| databaseId | Yes | The database ID to introspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output format (LLM-optimized) and use case, but omits important behavioral details: whether it requires specific permissions, whether it caches results, how large schemas are handled, or the exact response structure beyond 'tables and columns'. This is a gap for a read-only tool with no annotation coverage.
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: the first defines output, the second gives usage timing. No waste, front-loaded with core 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?
The description covers purpose, output format orientation, and a basic usage hint. However, for a tool with no annotations, no output schema, and only one parameter, it lacks adequate behavioral disclosure (permissions, performance, error handling) and alternative comparisons. It is 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%, so the single parameter (databaseId) is fully documented in the schema. The description adds no parameter-specific information. Baseline 3 is appropriate when the schema handles parameter semantics completely.
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?
States a specific verb (introspect) and resource (database schema: tables and columns), and specifies the output format orientation (optimized for LLM context). This clearly distinguishes it from sibling tools like get_database or list_databases, which imply metadata about the database itself rather than its internal schema.
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?
Provides timing guidance ('Use this before writing queries against an existing database'), which is useful context. However, it does not compare against alternatives (e.g., why not use get_database or query with DESCRIBE?), nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all databases on your account.
| 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 implies a safe bulk read and states account scope, but says nothing about pagination, result limits, ordering, or whether system databases are included. For a zero-arg list tool the gap is modest but real.
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 short sentence with no waste and the resource front-loaded. It is arguably too terse to be maximally useful, which keeps it off a 5.
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, so the description could have said what a returned database entry looks like, and there is no annotation coverage. For a simple zero-param list tool it is adequate but minimal.
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 takes zero parameters, so there is no parameter semantics to document and the baseline is 4. The description correctly implies no filtering arguments are accepted.
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?
States a clear verb+resource ('List all databases') and scopes it to 'your account'. It does not distinguish itself from siblings like get_database or list_migrations, but the name and phrase are unambiguous about what is returned.
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 prefer this over get_database (single) or other listing tools, and no prerequisites or exclusions stated. Usage is only implied by the verb 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all schema migrations that have been applied to a database, in order.
| Name | Required | Description | Default |
|---|---|---|---|
| databaseId | Yes | The database ID |
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 does usefully disclose behavioral scope — returns migrations already applied (not pending ones) and returns them ordered — but it omits whether the result is read-only-safe, whether there is pagination or a result cap, and any auth/permission requirements.
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 no filler; the resource is named first and the scoping qualifier ('applied', 'in order') follows. Every clause 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 one-parameter, no-annotation, no-output-schema listing tool, the description is nearly sufficient — it establishes what is listed and in what order. The remaining gap is limited to return-shape and pagination details, which the lack of an output schema leaves mildly open.
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% and the single databaseId parameter is fully documented in the schema, so the schema does the heavy lifting. The description adds only the implicit notion of 'a database', which maps to that parameter without adding format or constraint detail. Baseline 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?
States a specific verb ('List') and resource ('schema migrations') plus a qualifier ('applied to a database, in order'), so an agent can tell it apart from the sibling 'migrate' (which applies them) without opening the schema. It stops short of naming or contrasting any sibling, which keeps it at 4 rather than 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?
The description says nothing about when to call this versus alternatives such as 'migrate' (apply new migrations) or 'introspect_schema' (inspect current structure), nor any prerequisite like requiring an existing databaseId. Usage is only weakly implied by the phrase 'that have been applied'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a schema change (DDL) to a database. Migrations are tracked in _lobsterdb_migrations and are idempotent — safe to call multiple times with the same name.
Guidelines:
Use for all DDL: CREATE TABLE, ALTER TABLE ADD COLUMN, CREATE INDEX, etc.
Name migrations descriptively: "create_cards_table", "add_favorite_to_cards", "add_price_index"
ADDITIVE changes (add columns, create tables): apply without asking the user.
DESTRUCTIVE changes (DROP TABLE, DROP COLUMN, RENAME, changing column types): always confirm with the user before running.
Never use query for DDL — always use migrate so changes are tracked.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | DDL SQL to apply. Can include multiple statements separated by semicolons. | |
| name | Yes | Short snake_case migration name, e.g. "create_cards_table" or "add_favorite_column" | |
| databaseId | Yes | The database ID to migrate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden — and it does: idempotency is disclosed, the tracking table is named, and destructive-vs-additive behavior (and required user confirmation for the former) is spelled out. This is exactly the safety context an agent needs before a mutation.
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?
Front-loaded one-sentence purpose followed by a tightly scoped guidelines list. Every bullet earns its place — DDL scope, naming, additive/destructive handling, and the query alternative — with no filler.
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 no-annotation, no-output-schema mutation tool, the description covers operation scope, idempotency, tracking, and the safety decision tree. Nothing an agent needs to call this correctly is missing.
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 schema already documents all three parameters. The description's naming convention hint ('create_cards_table') largely repeats the schema's own example, adding only marginal value beyond structured data; baseline 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?
States a specific verb+resource — applying a DDL schema change to a database — and adds scope detail (tracked in _lobsterdb_migrations, idempotent). It explicitly distinguishes itself from the sibling 'query' tool, so an agent can tell them apart without opening schemas.
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?
Explicit when-to-use: all DDL including CREATE TABLE, ALTER TABLE, CREATE INDEX. Names the alternative and forbids it ('Never use query for DDL'). Also splits additive vs destructive operations with a clear confirm-with-user rule for destructive ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SQL query against a database. Use $1, $2, ... for parameters. Results are sanitized for safe LLM context.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL statement to execute. Use $1, $2, ... for parameters. | |
| params | No | Query parameters corresponding to $1, $2, ... placeholders | |
| databaseId | Yes | The database ID to query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it manages only one behavioral disclosure: results are sanitized for safe LLM context. It never states that SQL can be destructive (DROP/DELETE/UPDATE), whether transactions are supported, row or timeout limits, or permission requirements — all critical for a tool that can write and destroy data.
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?
Three short sentences, front-loaded with the core action, with no filler. Each sentence carries information, though the sanitization note is vague about what 'sanitized' actually means and could have been replaced with more actionable detail.
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 annotations and no output schema, the description should explain return shape, result limits, and destructive potential. Instead it covers only execution and a vague sanitization note, leaving an agent unable to predict result format or the consequences of a write statement.
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 schema already documents sql, params, and databaseId fully. The description restates the $1/$2 placeholder convention already present in the schema, adding no new meaning about types, binding rules, or limits. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Execute a SQL query against a database.' An agent immediately knows this runs SQL, which no sibling (snapshot, migrate, introspect_schema, create_database) does. It does not, however, explicitly distinguish itself from siblings or clarify scope such as which SQL dialects or statement types are permitted.
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 only usage instruction is the placeholder syntax ('Use $1, $2, ... for parameters'), which is a calling convention rather than guidance on when to choose this tool over siblings like introspect_schema or migrate. No conditions, exclusions, or alternatives are given; the agent must infer usage from the purpose sentence alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a point-in-time snapshot of a database. Requires Builder tier or higher.
| Name | Required | Description | Default |
|---|---|---|---|
| databaseId | Yes | The database ID to snapshot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It does disclose one genuine behavioral constraint — the Builder tier or higher requirement — which is exactly the kind of permission context the rubric credits. However, it says nothing about whether snapshot creation is synchronous or async, how long it takes, or any cost/retention implications of a mutating 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?
Two short sentences, front-loaded with the core action and followed by the access prerequisite; nothing is redundant. It is efficient, though its brevity leaves behavioral gaps rather than padding them.
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 one well-documented required parameter and no output schema, the description need not explain return values. But for a mutating tool with zero annotation coverage, the agent still lacks information about the operation's behavior (async? blocking? retention?), so the definition is only minimally 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% for the single parameter (databaseId), so the schema already explains it fully. The description adds no format, constraint, or edge-case detail beyond what the schema provides, making the baseline 3 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?
States a specific verb and resource: 'Create a point-in-time snapshot of a database.' The scope is unambiguous and no sibling tool (create_database, migrate) overlaps with snapshotting. It stops short of any sibling differentiation, but none is genuinely needed here.
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 gives no when-to-use guidance, no alternatives, and no exclusions. The only qualifier is a plan-tier prerequisite ('Builder tier or higher'), which gates access but does not tell the agent when this tool is the right choice over e.g. migrate or create_database.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0create_databasedelete_databaseget_accountget_databaseintrospect_schemalist_databaseslist_migrationsmigratequerysnapshotScored across 10 tools
Each tool targets a distinct resource or action: database lifecycle, SQL querying, schema introspection, migrations, snapshots, and account details. The query-vs-migrate boundary is explicitly clarified, and no two tools appear to do the same thing.
Most tools follow a clear verb_noun pattern (create_database, get_database, list_databases, introspect_schema, list_migrations). Minor deviations are snapshot (bare noun) and query/migrate (verbs without an explicit object).
Ten tools is well-scoped for a database provisioning and management server. Each tool earns its place, covering account, database CRUD, querying, schema introspection, migrations, and snapshots without excessive redundancy.
Core database and query workflows are covered, but database CRUD lacks an update/rename operation and snapshots can only be created, not listed, restored, or deleted. Migrations can be applied and listed but not rolled back or dropped, leaving some notable lifecycle dead ends.
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
Your Supabase account in natural language: run SQL, apply migrations, manage tables, storage, edge f
Multi-tenant database orchestration: isolated Postgres, MySQL, MongoDB, Redis tenants on demand.
Manage Supabase projects end to end across database, auth, storage, realtime, and migrations. Moni…
