Skip to main content
Glama
Sign In
SQLite Explorer MCP

SQLite Explorer MCP

by msharsha565-create
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_tables

Retrieves the names of all tables and views in a SQLite database so AI agents can discover available data before writing queries.

Instructions

Names of the tables and views in the database.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_tables"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
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 behavioral burden; it does not state that the operation is a non-mutating read, nor whether system/catalog tables are included or which schema/connection scope applies. The gap is partially offset by the tool taking zero parameters and having an output schema, making behavior largely predictable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and waste-free, but it is not front-loaded with an action verb, which weakens scannability. Brevity here reflects under-specification rather than disciplined economy.

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 trivial no-param enumerator with an output schema, the description is minimally sufficient, but it omits scope information (which database/schema/connection the listing covers) and whether views are separated from tables. Without annotations, a sentence covering read-only nature and scope would complete it.

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 takes zero parameters, so the baseline applies; there is no parameter semantics to explain and the description correctly spends no words on it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (tables and views in the database) but is a noun fragment with no verb, so the operation (list/enumerate) is inferred rather than stated. It is distinguishable from describe_table and get_schema_ddl mainly because those siblings have their own explicit names, not because the description differentiates.

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?

There is no guidance on when to use this versus describe_table or get_schema_ddl, even though all three inspect schema metadata. An agent must guess that this is the enumeration entry point before drilling into columns or DDL.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools