Relational DB Seeder MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATABASE_URL | Yes | The database connection URL for SQLite or PostgreSQL |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {
"tasks": {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_database_statusA | Check the connection status and details of the active database. When to use: Use this tool at the start of a session or when you need to verify which database engine (SQLite or PostgreSQL) is connected and list the available tables. |
| get_schemaA | Retrieve the complete schema layout of the active database. When to use: Call this tool before writing queries or generating mock data payloads. It provides columns, data types, nullability, primary keys, and foreign key relationships for all tables, which is necessary to plan referential insert operations. |
| insert_graphA | Seed mock, test, or relational data rows into the database. Supports inserting entries into multiple tables at the same time in a single payload. When to use: This is the PREFERRED and recommended tool for inserting data records into the database. Use this instead of executing raw SQL INSERT statements. It handles table dependencies, resolves auto-generated parent IDs dynamically, and ensures safe transactions. CRITICAL: The payload must map table names to a list of DICTIONARIES (not lists or arrays of values). Each dictionary must map column names to their values. Example input payload: { "users": [ { "__temp_id": "u1", "name": "Alice Smith", "email": "alice@example.com" } ], "posts": [ { "title": "My First Post", "author_id": "ref:users:u1" } ] } Args: payload: Dict mapping table name to a list of dict objects representing rows. Rows can specify "__temp_id" (e.g. "u1"). Foreign keys can refer to parents using "ref:parent_table:temp_id" (e.g. "ref:users:u1"). |
| execute_queryA | Execute arbitrary SQL statements on the connected database. When to use: Use this tool for read operations (e.g., SELECT queries to verify data), schema modification (e.g., CREATE TABLE, ALTER TABLE, DDL statements), or updates. DO NOT use this for inserting mock/seed records; use insert_graph instead. Args: query: SQL string to execute. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool serves a clearly distinct purpose: status check, schema retrieval, graph-based seeding, and arbitrary SQL execution. The descriptions explicitly distinguish insert_graph from execute_query, leaving no ambiguity about when to use which.
All tool names follow the same verb_noun pattern in snake_case: get_database_status, get_schema, insert_graph, execute_query. This consistent convention makes the toolset easy to learn and predict.
With only 4 tools, the server is tightly focused on its purpose of seeding relational databases. Each tool is necessary and none is redundant, making the scope well-calibrated.
The toolset covers the full workflow: inspecting database status, reading schema, inserting relational data with dependency handling, and executing arbitrary SQL for validation or modifications. No obvious gaps for the seeder domain.