android-sqlite-mcp

by Feliicks

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.2
Disambiguation5/5
Each tool targets a distinct stage in the workflow: discovering packages, listing databases, pulling a database, checking cache status, listing tables, getting schema, and executing queries. There is no overlap between tools, even between list_databases and get_cache_status which clearly distinguish remote vs. cached databases.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_packages, pull_database, get_schema, execute_query). The naming style is uniform and predictable, with no mixed conventions or vague verbs.
Tool Count5/5
The server has 7 tools, well within the ideal range of 3-15. Each tool serves a distinct and necessary step in the pipeline from device discovery to SQL querying, with no redundancy or bloat.
Completeness5/5
The toolset covers the entire lifecycle of working with Android SQLite databases: discovery (list_packages, list_databases), extraction (pull_database), cache management (get_cache_status), introspection (list_tables, get_schema), and querying (execute_query). There are no obvious gaps for the stated purpose.
Average 3.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 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 must carry the full behavioral burden. It mentions that write operations are possible, implying mutation, but omits critical details such as whether changes are persisted, reversible, or if any confirmation is required. This is a significant transparency gap for a potentially destructive raw SQL tool.
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?
Two short, direct sentences with no filler. The primary verb and resource are front-loaded, and each sentence earns its place by stating the core action and the type of operations allowed.
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?
For a complex tool that executes arbitrary SQL with no output schema and no annotations, the description is incomplete. It does not explain return value format, error handling, side effects, or how to use the optional params parameter. The tool's power and risk demand richer guidance.
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 coverage is 100%, so the schema already documents all parameters adequately. The description adds minimal extra meaning beyond 'raw SQL' and 'cached database', which somewhat enriches the context but does not materially enhance parameter understanding beyond the schema.
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 tool executes a raw SQL query on a cached database and explicitly enumerates supported operations (SELECT/INSERT/UPDATE/DELETE). This distinguishes it from sibling tools like list_packages and get_schema, which are introspection-only.
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 provides some implied usage context (e.g., 'raw SQL query on a cached database') but does not explicitly state when to prefer this tool over siblings, or mention prerequisites like checking schema or listing tables first. No exclusions or alternative tool references are given.
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?
Since no annotations are provided, the description is the sole source of behavioral transparency. It does disclose the method (adb run-as) and destination (local cache), which is helpful, but it doesn't mention whether the operation is read-only on the device, what happens if files already exist, expected permissions, or failure scenarios. These gaps make it only partially transparent.
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, compact sentence that front-loads the core action and includes key details (SQLite, WAL, source, destination, mechanism). Every word contributes to understanding; no filler or redundancy.
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?
Although the tool is simple (2 required parameters, no output schema), the description omits important context such as return value (e.g., stored path), usage prerequisites, and edge-case behavior. The lack of annotations increases the burden on the description, and it does not fully cover what an agent needs to know to invoke correctly and interpret results.
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 already describes both parameters (appId and dbName) with 100% coverage. The description does not add any additional meaning to the parameters, such as format constraints or examples beyond what the schema provides. Baseline 3 is appropriate.
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 action ('Extracts'), the resource ('SQLite database and its WAL files'), the source ('Android device'), and destination ('local cache'), making it instantly distinguishable from sibling tools that list or query rather than pull data. The specific mention of adb run-as further clarifies the scope.
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 when to use it (when you need to extract an app's database files) but doesn't explicitly state alternatives or exclusions. For example, it doesn't mention that execute_query is for live queries or that list_databases is for discovery. No explicit 'use this instead of' guidance is provided.
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, the description must fully disclose behavior. It clearly indicates a read-only metadata retrieval, but does not mention potential edge cases, error handling, or whether the database must be cached. The basic behavior is clear, but additional 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action ('Returns') and the key output (DDL schema). No extraneous words or redundant details; it is concise and well-structured.
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?
For a simple tool with fully documented parameters and a self-explanatory output (DDL), the description is reasonably complete. It could mention that views are handled (already implied by schema) or return format, but the absence of an output schema and annotations makes this a minor gap. Overall, it covers the essential context.
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 provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description itself adds no parameter-level detail beyond what the schema already states, so it neither improves nor worsens the semantic clarity.
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 a specific verb ('Returns') and resource ('DDL schema for a specific table in a cached database'), which distinguishes it from sibling tools like list_tables or execute_query. It is unambiguous and directly describes the tool's purpose.
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 does not explicitly state when to use this tool over alternatives, nor does it mention exclusions. Usage is implied: it is for inspecting the schema of a specific table. No explicit guidance or alternative references are provided, so it falls short of a 4.
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?
No annotations are provided, so the description carries the full burden. It indicates a read-only listing operation but does not disclose output format, permissions, or prerequisites like device connection or app installation.
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, front-loaded sentence with no filler, earning maximum conciseness.
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?
For a simple one-param list tool, the description is adequate. It could mention return format or relationship to siblings, but given the low complexity, it is sufficiently complete.
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 schema provides 100% coverage for the single appId parameter, and the description reinforces its role without adding new semantic details beyond what the schema already states.
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 verb 'Lists' and the resource 'SQLite database files' with scope 'internal storage of a specific Android app', making it distinct from sibling tools like list_tables or pull_database.
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 by requiring a specific appId but does not explicitly state when to use this tool over alternatives. No exclusions or when-not-to-use conditions are provided.
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?
No annotations are provided, so the description carries the burden. It discloses that the database is cached and row counts are approximate, which adds useful context. However, it doesn't mention whether it's read-only, requires permissions, or any other behavioral nuances.
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?
A single, front-loaded sentence that announces the operation and the key output attribute (row counts). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with comprehensive schema and no complex side effects, the description sufficiently explains what the agent will receive. Output (tables/views with row counts) is stated, and necessary inputs are in schema.
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 coverage is 100% for both parameters (appId, dbName), so the schema already documents them. The description adds no additional parameter-specific detail beyond referring to a 'cached database'.
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?
Description clearly states it lists all tables and views in a cached database with approximate row counts. The specific verb 'list' and resource 'tables and views' distinguishes it from sibling tools like list_databases and list_packages.
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?
Implied usage is clear: use to inspect table/view names and row counts within a database. No explicit exclusions or alternative recommendations, but context is clear. Sibling tools provide contrast, but description doesn't name them.
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 of behavioral disclosure. It indicates the operation is non-destructive ('Returns information'), but does not elaborate on potential nuances such as whether the cache might be stale, whether any refresh is triggered, or what happens if no databases are cached. This is adequate for a simple read-only getter but leaves some behavioral traits unstated.
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, well-structured sentence that front-loads the main action ('Returns information') and then specifies the scope ('currently cached Android SQLite databases ready to be queried'). There is no fluff or redundant phrasing, making it highly concise and easy to parse.
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?
For a zero-parameter tool with no output schema, the description provides adequate context by specifying the exact subject (cached databases) and their state (ready to be queried). However, it does not enumerate what 'information' will be returned, which is a minor gap given the absence of an output schema. Overall, it is sufficiently complete for a simple status query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information to explain. The rubric prescribes a baseline of 4 for tools with no parameters, and the description correctly makes no reference to parameters. It adds no unnecessary parameter-related content.
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 tool's function: it returns information about currently cached Android SQLite databases that are ready to be queried. The verb 'returns' combined with the specific resource ('cached Android SQLite databases ready to be queried') distinguishes it from sibling tools like list_databases, which likely lists all available databases rather than only cached ones.
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 implies the tool should be used when the user needs information about databases that are already cached and ready for querying. This gives clear context for the primary use case, though it does not explicitly mention alternatives or when not to use it. The sibling tool list_databases might be more appropriate for a complete list, but no exclusions are stated.
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. It accurately discloses the read-only nature of the operation ('lists') and the optional filtering behavior. While it does not detail return format or permissions, the simplicity of the operation makes the description adequate.
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 sentence, front-loaded with the main verb and object, and contains no filler. Every word contributes meaning, making it exceptionally concise and well-structured.
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?
For a simple list tool with one optional parameter and no output schema, the description gives enough context about what it does and how filtering works. It does not explain the exact output format, but that is not critical for such a straightforward operation.
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 already provides full coverage (100%) with the 'query' parameter description. The tool description repeats the filtering concept without adding new detail about syntax or behavior, so it neither enhances nor contradicts the schema, staying at the baseline.
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 uses the specific verb 'lists' with the resource 'installed Android application packages on the device', making the tool's function immediately clear. It also distinguishes from sibling tools like list_databases and execute_query, which operate on databases rather than packages.
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 clearly implies when to use the tool: when listing installed Android packages, with an optional query filter. However, it does not explicitly name alternative tools or state exclusion criteria, but the context of sibling tools makes the intended use obvious.
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:

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

Score Badge

Copy to your README.md:

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

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/Feliicks/android-sqlite-mcp'

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