Provides tools for interacting with SQLite databases, enabling AI agents to create databases, list tables, query data, add records, and explore schemas on local SQLite database files.
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., "@SQLite MCP Server list all tables in the database"
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.
SQLite MCP Serverλ AIκ° λΉμ μ λ‘컬 λ°μ΄ν°μ μ κ·Όνκ³ , λΆμνλ©°, μ§μμ κ΄λ¦¬ν μ μκ² λλ κ°μ₯ λ¨μνκ³ κ°λ ₯ν μΈν°νμ΄μ€μ λλ€.
Zero-Config: API Keyλ 볡μ‘ν μλ² μ€μ μ΄ νμ μμ΅λλ€. μ€μ§ .db νμΌ νλλ©΄ μΆ©λΆν©λλ€.
Portable Brain: νλ‘μ νΈ ν΄λλ§λ€ λ 립λ SQLite DBλ₯Ό λμ΄ AIκ° ν΄λΉ νλ‘μ νΈμ 'κΈ°μ΅'μ λ‘컬μ μ μ₯νκ³ κΊΌλ΄ μΈ μ μκ² ν©λλ€.
Security First: κ°λ ₯ν μ½κΈ° μ μ© λͺ¨λμ SQL νν°λ§μ ν΅ν΄ μμ ν λ°μ΄ν° κ΄λ¦¬λ₯Ό 보μ₯ν©λλ€.
Related MCP server: anydb-mcp
π Database Discovery: νΉμ κ²½λ‘ λ΄μ λͺ¨λ SQLite νμΌ(.db, .sqlite, .sqlite3)μ μλμΌλ‘ μ€μΊν©λλ€.
πΊ Schema Introspection: DBμ μ 체 ꡬ쑰λ₯Ό νμ νμ¬ AIκ° λ°μ΄ν°μ λ§₯λ½μ μλ²½ν μ΄ν΄νκ² λμ΅λλ€.
β‘ Secure Querying: SELECT μΏΌλ¦¬λ§ νμ©νλ κ°λ ₯ν 보μ λͺ¨λλ‘ λ°μ΄ν° λΆμμ μνν©λλ€.
π Note & Record Support: AIκ° μμ΄λμ΄λ λ©λͺ¨λ₯Ό νΉμ DBμ μ¦μ κΈ°λ‘ν μ μλ μ μ© λꡬλ₯Ό μ 곡ν©λλ€.
π DB Creation: νμν κ²½μ° μλ‘μ΄ SQLite λ°μ΄ν°λ² μ΄μ€ νμΌμ μ¦μ μμ±ν μ μμ΅λλ€.
uv μ€μΉ κΆμ₯ λλ Python 3.10 μ΄μ.
Windowsμ 보μ μ μ±
(Smart App Control λ±)μΌλ‘ μΈν΄ uvx μ¬μ© μ μ€νμ΄ μ°¨λ¨λ μ μμ΅λλ€. μ΄λ₯Ό λ°©μ§νκΈ° μν΄ ν¨ν€μ§λ₯Ό λ‘컬 λκ΅¬λ‘ μ€μΉνμ¬ μ¬μ©νλ κ²μ κΆμ₯ν©λλ€.
# uv μ¬μ© (κΆμ₯)
uv tool install sqlite-mcp-server
# λλ pip μ¬μ©
pip install sqlite-mcp-serverμ€μΉ νμλ μ΄λμλ λͺ λ Ήμ΄λ‘ μ€νν μ μμ΅λλ€:
sqlite-mcp-serverμ€μΉ μμ΄ λΉ λ₯΄κ² μ€νν΄λ³΄κ³ μΆμ λ μ¬μ©ν©λλ€ (Windowsμμ os error 4551 λ°μ μ μ μ€μΉ λ°©λ²μ μ¬μ©νμΈμ):
uvx sqlite-mcp-serverλ€μ λͺ λ Ήμ΄λ₯Ό μ€ννμ¬ μλ²λ₯Ό μΆκ°ν©λλ€:
gemini mcp add sqlite-mcp uvx sqlite-mcp-serverμ§μ μ€μ νλ €λ©΄ .gemini/settings.json νμΌμ λ€μ μ€μ μ μΆκ°νμΈμ:
{
"mcpServers": {
"sqlite-mcp": {
"command": "uvx",
"args": ["sqlite-mcp-server"]
}
}
}Claude Desktop μ€μ νμΌμ λ€μ λ΄μ©μ μΆκ°νμΈμ:
{
"mcpServers": {
"sqlite-mcp": {
"command": "uv",
"args": [
"tool",
"run",
"--from",
"sqlite-mcp-server"
]
}
}
}λ€μ λͺ λ Ήμ΄λ₯Ό μ€ννμ¬ μλ²λ₯Ό μΆκ°ν©λλ€:
claude mcp add sqlite-mcp -- uvx sqlite-mcp-servercreate_database(db_path): μλ‘μ΄ SQLite λ°μ΄ν°λ² μ΄μ€ νμΌμ μμ±ν©λλ€.
list_databases(path): μ§μ λ κ²½λ‘μ SQLite DB λͺ©λ‘μ λ°νν©λλ€.
search_databases(path, query): μ§μ λ κ²½λ‘ λ΄μ λͺ¨λ DBλ₯Ό κ²μνμ¬ νΉμ ν€μλ(ν
μ΄λΈλͺ
, 컬λΌλͺ
)κ° ν¬ν¨λ μμΉλ₯Ό μ°Ύμ΅λλ€.
get_schema_summary(db_path): DBμ λͺ¨λ ν
μ΄λΈκ³Ό μ»¬λΌ κ΅¬μ‘°λ₯Ό μμ½ν΄μ 보μ¬μ€λλ€.
list_tables(db_path): DB λ΄μ λͺ¨λ ν
μ΄λΈ λͺ©λ‘μ κ°μ Έμ΅λλ€.
describe_table(db_path, table_name): νΉμ ν
μ΄λΈμ μ€ν€λ§μ μν λ°μ΄ν°λ₯Ό 보μ¬μ€λλ€.
add_record(db_path, table_name, title, content): λ°μ΄ν°λ² μ΄μ€μ μλ‘μ΄ λ μ½λλ₯Ό μΆκ°ν©λλ€ (ν
μ΄λΈ μλ μμ± μ§μ).
execute_query(db_path, query): SELECT 쿼리λ₯Ό μ€ννμ¬ λ°μ΄ν°λ₯Ό λΆμν©λλ€.
# μμ‘΄μ± μ€μΉ
uv sync
# μλ² λ‘컬 μ€ν
uv run sqlite-mcpMIT
Add a new record to the specified table in the database. If the table doesn't exist, it will be created with columns: id, title, content, and created_at.
| Name | Required | Description | Default |
|---|---|---|---|
| db_path | Yes | ||
| table_name | Yes | ||
| title | Yes | ||
| content | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 automatic table creation with specific columns, but does not address behavior if the table exists with different schema or error conditions.
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 two sentences, front-loads the main purpose, and adds conditional behavior without any fluff. 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?
Given 0% schema coverage and no annotations, the description explains the core function and auto-creation, but lacks information about return values (even though output schema exists) and error conditions.
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 0%, so the description must explain parameters. It mentions record fields (title, content) but does not explain db_path or table_name, leaving their meaning and constraints unclear.
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 adds a record to a specific table and handles automatic table creation with fixed columns. This distinguishes it from siblings like list_tables or describe_table.
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 does not provide explicit guidance on when to use this tool versus alternatives like execute_query; it only implies its use for adding records, but does not exclude other methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new empty SQLite database file at the specified path.
| Name | Required | Description | Default |
|---|---|---|---|
| db_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 basic purpose but does not disclose important behavioral traits such as whether the file can be overwritten, required permissions, or error handling when the path is invalid.
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, concise and front-loaded. However, it could include more structure or additional context 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?
The tool is simple with one parameter, and an output schema exists. However, the description does not cover important context such as whether the directory must exist or what happens if a file already exists at that path, making it slightly 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?
Schema description coverage is 0%, but the description only mentions 'at the specified path' without adding any detail about the parameter format, constraints, or expected input beyond the schema name.
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 that the tool creates a new empty SQLite database file at a given path, with a specific verb and resource. It clearly distinguishes from other tools like list_databases or execute_query which operate on existing databases.
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_databases or search_databases. There is no mention of prerequisites or 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 the schema (columns) and a few sample rows from the specified table.
| Name | Required | Description | Default |
|---|---|---|---|
| db_path | Yes | ||
| table_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavior. It states outputs (schema and sample rows) but does not specify how many sample rows or any constraints (e.g., performance on large tables). The term 'a few' is vague but does not contradict any structured fields.
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 front-loads the main action and result. Every word is necessary; no fluff or redundancy.
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 (2 parameters) and presence of an output schema, the description sufficiently explains the tool's purpose and output. However, it could clarify the number of sample rows or mention error handling, but these are minor 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 0%, so the description should add meaning. It mentions 'specified table' but does not explain what db_path or table_name represent, leaving their semantics to the schema (which only provides types and names).
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 retrieves schema and sample rows from a table, using specific verbs 'Get' and identifying the resource 'schema' and 'sample rows'. It distinguishes from siblings like execute_query (which runs arbitrary queries) and list_tables (which only lists names).
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 after selecting a table, but provides no explicit guidance on when to use it versus alternatives like get_schema_summary or execute_query. No when-not-to-use or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SELECT query on the specified SQLite database. Strictly enforced as READ-ONLY: only SELECT statements are allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| db_path | Yes | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and clearly discloses the read-only constraint and SELECT-only policy. It adds behavioral context beyond basic operation, though it does not detail error handling or concurrency 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?
Two sentences, each essential. The first states the primary action, the second adds a critical constraint. No extraneous words, information is 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?
For a simple tool with 2 parameters and an output schema, the description covers the core purpose and restriction. However, it omits details like database path format, query limitations, and error handling. Given minimal complexity, it is decent but could be more 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 0%, yet the description adds no details about the parameters (db_path, query) beyond the schema. It does not specify expected formats, validation, or constraints, failing to compensate for the lack of schema descriptions.
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 executes SELECT queries, specifying the action (execute), resource (SQLite database), and scope (SELECT only). It distinguishes from siblings like add_record and create_database, which modify data or create structures.
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 explicitly states that only SELECT statements are allowed and that it is read-only, providing clear guidance on when to use (for reading data) and when not (for modifications). It implicitly points to siblings like add_record for writes, though not naming them directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive summary of the entire database schema, including all tables and their column definitions.
| Name | Required | Description | Default |
|---|---|---|---|
| db_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it returns schema summary but omits behavioral details like potential performance impact or necessary permissions for read 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?
Single sentence that directly states the tool's function, but could be more structured by separating parameter info.
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?
Output schema exists, so return values are covered; however, lack of parameter guidance and usage context leaves gaps for a one-parameter tool.
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 0%, and the description provides no explanation of the required 'db_path' parameter (format, examples, or where to obtain 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?
Clearly states verb 'Get' and resource 'comprehensive summary of the entire database schema', distinguishing it from siblings like describe_table (single table) and list_tables (table names).
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?
Implies usage when a full schema overview is needed, but no explicit when-to-use or when-not-to-use compared to alternatives like describe_table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all SQLite database files (.db, .sqlite, .sqlite3) in the specified directory. Default is the current directory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation (listing files) but does not explicitly state that it is non-destructive, nor does it describe behavior like recursion depth or error handling.
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 sentences front-load the purpose and parameter, with no redundant or extraneous 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 presence of an output schema and the simplicity of the tool, the description covers the primary purpose and parameter. It could optionally mention search depth (top-level only or recursive), but it is generally sufficient.
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 has 0% description coverage on the 'path' parameter, but the description adds meaning by identifying it as a directory and noting the default. However, it lacks details on format, relative vs. absolute paths, or validation.
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 it lists SQLite database files (.db, .sqlite, .sqlite3) in a specified directory. This specific verb+resource combination distinguishes it from sibling tools like list_tables and search_databases.
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 for discovering database files in a directory, but it does not provide explicit guidance on when to use this tool versus alternatives or mention any prerequisites or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in the specified SQLite database.
| Name | Required | Description | Default |
|---|---|---|---|
| db_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only implies a read-only operation ('list') but does not explain behavior on missing databases, permissions, side effects, or output format. This is insufficient for a tool with no annotations.
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 and front-loaded. However, it sacrifices necessary detail for brevity, making it less helpful for an agent. It earns a 3 for being non-redundant but incomplete.
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 an output schema, the description does not explain what the tool returns or any behavioral context. With no annotations and a single parameter that lacks clarification, the description is too sparse to provide a complete understanding for safe agent 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?
Schema description coverage is 0%, so the description must add meaning beyond the schema. It mentions 'specified SQLite database' but does not explain the format, constraints, or examples for the 'db_path' parameter. The description adds minimal value over the schema definition.
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 tables in the specified SQLite database'. This distinguishes it from siblings like 'list_databases' or 'describe_table', which target different resources or actions.
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, exclusions, or context that would help an agent decide between this and similar tools like 'get_schema_summary'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a keyword in all SQLite databases within a directory. Searches table names and column names to help discover relevant data.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it searches table and column names, but no annotations exist. Does not mention scope boundaries, error conditions, or performance considerations.
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 sentences with no redundancy. Action and scope are front-loaded, second sentence adds relevant detail concisely.
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 with two parameters and an output schema. Description is adequately complete for its complexity, though could mention that it targets SQLite databases only.
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 0%; description only implies 'path' is a directory and 'query' is a keyword, but does not explicitly define them or provide format details.
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 it searches a keyword across all SQLite databases in a directory, specifically table and column names. It distinguishes from siblings like list_databases or describe_table, though not explicitly stating the difference.
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., list_tables, execute_query). Lacks when-not conditions or prerequisites.
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. Dates show when Glama detected each change.
v0.1.7add_recordcreate_databasedescribe_tableexecute_queryget_schema_summarylist_databaseslist_tablessearch_databasesEach tool has a clearly distinct purpose: database creation, table listing, schema inspection, querying, record insertion, and database search. No overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern (e.g., create_database, list_tables, execute_query) using snake_case, making the set predictable and easy to navigate.
8 tools cover essential SQLite operations like creating databases, inserting records, querying, and exploring schema. The number is well-scoped without being excessive or insufficient.
The tool set lacks update and delete operations, and execute_query is restricted to SELECT. This creates notable gaps for full CRUD coverage, though basic operations are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
GibsonAI MCP server: manage your databases with natural language
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors β no code.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/stevefordev/sqlite-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
