mcp-server-sqlite

by ofershap

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
The tools have some overlap that could cause confusion, particularly between 'schema' and 'table_info', which both provide table structure information. However, 'explain', 'list_databases', and 'query' are clearly distinct in purpose, and descriptions help differentiate the overlapping tools.
Naming Consistency4/5
The naming is mostly consistent with a verb_noun pattern (e.g., 'list_databases', 'table_info'), but 'explain' and 'query' deviate as standalone verbs without nouns. This minor inconsistency does not severely impact readability or predictability.
Tool Count5/5
With 5 tools, the server is well-scoped for SQLite database operations. Each tool serves a clear and necessary function, such as listing databases, querying, and inspecting schemas, making the count appropriate without being too sparse or bloated.
Completeness4/5
The toolset covers core SQLite operations like listing databases, querying, and schema inspection, with minor gaps such as the lack of write operations (e.g., insert, update, delete) and database management tools (e.g., create, delete). Agents can work around these gaps for read-only use cases.
Average 3.5/5 across 5 of 5 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool explains query plans and helps optimize queries, but doesn't describe what the output looks like (e.g., textual explanation, structured data), whether it's read-only or has side effects, or any constraints like file access permissions or rate limits. For a tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that directly state the purpose and benefit. There's no wasted verbiage, and it efficiently communicates the core functionality. However, it could be slightly improved by integrating usage guidance more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of SQL query analysis and the lack of annotations and output schema, the description is incomplete. It doesn't explain the return format, potential errors, or behavioral traits, leaving gaps for an agent to understand how to interpret results. For a tool with no structured output and no annotations, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('db' as path to file, 'sql' as SQL query). The description adds no additional parameter semantics beyond what the schema provides, such as format details or examples. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Explain the query plan for a SQL query (EXPLAIN QUERY PLAN).' It specifies the verb ('explain') and resource ('query plan'), and adds the helpful context 'Helps optimize queries.' However, it doesn't explicitly differentiate from sibling tools like 'query' or 'schema,' which could handle similar SQL-related tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'Helps optimize queries,' which implies usage for performance tuning, but doesn't specify scenarios, prerequisites, or exclusions compared to siblings like 'query' or 'schema.' This lack of explicit when/when-not guidance limits its utility for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists files but does not describe how it behaves—e.g., whether it recursively scans subdirectories, handles errors like inaccessible paths, returns file metadata or just names, or has any rate limits. This leaves significant gaps in understanding the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates what the tool does, making it easy to parse and understand quickly. Every part of the sentence earns its place by specifying file types and location.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally complete but lacks depth. It covers the basic purpose and resource but omits behavioral details and usage context. For a simple listing tool, this might be adequate, but it does not fully compensate for the absence of annotations or output schema, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting the single parameter 'directory' with its type, default, and purpose. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, the 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List') and resource ('SQLite database files (.db, .sqlite, .sqlite3) in a directory'), distinguishing it from sibling tools like 'explain', 'query', 'schema', and 'table_info' which perform different operations on databases rather than listing files. It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparisons to sibling tools, leaving the agent to infer usage based on the purpose alone. This lack of explicit context reduces its helpfulness for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the tool's behavior (retrieving metadata) and output content (columns, types, constraints, row count), but lacks details on permissions, error handling, or performance characteristics. It doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and lists specific metadata retrieved. Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only metadata tool with no annotations and no output schema, the description adequately covers what information is returned. However, it lacks details on output format (e.g., structured JSON), error cases, or limitations, which would be helpful given the absence of structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (db path and table name). The description adds no additional parameter semantics beyond what the schema provides, maintaining the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed info about a single table'), specifying what information is retrieved (columns, types, constraints, row count). It distinguishes from sibling tools like 'list_databases' (lists databases) and 'schema' (likely shows overall schema), but doesn't explicitly differentiate from 'explain' or 'query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed table metadata is needed, but provides no explicit guidance on when to use this versus alternatives like 'schema' (which might show broader schema info) or 'query' (which retrieves data). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's behavior as a read operation that returns schema information, but doesn't mention error handling, performance characteristics, or output format details. It adequately describes what the tool does without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the tool's purpose and scope. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no annotations and no output schema, the description provides adequate context about what the tool does. However, it doesn't describe the return format or structure, which would be helpful given the lack of output schema. The description is complete enough for basic understanding but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the single parameter 'db' as a path to a database file. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the schema') and resource ('SQLite database'), with precise scope ('all tables with columns and row counts'). It distinguishes from sibling tools like 'query' (executes queries) and 'table_info' (likely provides detailed table metadata) by focusing on comprehensive schema retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing database structure information, but doesn't explicitly state when to use this tool versus alternatives like 'table_info' or 'explain'. It provides basic context (SQLite databases) but lacks explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the tool executes SQL queries, returns formatted tables, and is 'Read-only by default' (implying safety and restrictions). However, it could add more context, such as error handling, performance implications, or specific limitations beyond the default read-only mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two concise sentences that directly convey the tool's purpose and key behavior. Every sentence earns its place by providing essential information without redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (SQL execution), no annotations, and no output schema, the description is mostly complete. It covers the core functionality, default behavior, and output format. However, it could improve by addressing error cases, result limitations (e.g., large datasets), or more details on the 'readonly' parameter's enforcement, which would enhance completeness for a tool with no structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters ('db', 'sql', 'readonly') with descriptions. The description adds minimal value beyond the schema, as it doesn't provide additional syntax, format details, or usage examples for parameters. The baseline score of 3 is appropriate since the schema handles most of the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute a SQL query'), target resource ('against a SQLite database'), and output format ('Returns results as a formatted table'). It distinguishes from siblings like 'explain' (query analysis), 'list_databases' (database enumeration), 'schema' (structure overview), and 'table_info' (table metadata) by focusing on direct query execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Execute a SQL query against a SQLite database') and implicitly suggests alternatives through sibling tool names (e.g., use 'explain' for query analysis, 'schema' for structure). However, it lacks explicit guidance on when NOT to use it or detailed comparisons with alternatives, such as when to prefer 'explain' over 'query' for debugging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ofershap/mcp-server-sqlite'

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