Provides read-only access to a PostgreSQL database, enabling AI assistants to list schemas and tables, inspect table structures, and run SELECT queries to answer questions about the data.
Click on "Deploy 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., "@Qora How many customers signed up this month?"
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.
Talk to your data. Get clear answers, insights, and analysis.
Qora lets AI assistants like Cursor and Claude safely explore your database and answer questions about your data in plain English.
Ask things like:
"How many orders did we receive last month?"
"Which products are selling the most?"
"Show me the tables related to customers."
Qora looks up the answers directly from your database and gives them back to your AI assistant.
Qora is read-only by design. It can inspect and query your data, but it cannot insert, update, or delete anything.
flowchart LR
You["You ask a question"] --> AI["AI assistant<br/>(Cursor, Claude, …)"]
AI -->|"uses Qora tools"| Qora["Qora"]
Qora -->|"explore & read-only queries"| DB[("Your database")]
DB -->|"rows & schema info"| Qora
Qora -->|"safe results"| AI
AI -->|"clear answer"| YouYou ask something.
Your AI assistant calls Qora.
Qora looks up schemas/tables or runs a read-only query.
Results go back to the assistant, which answers you.
Related MCP server: GraphJin
Qora gives your AI assistant safe, read-only access to the database.
Discover schemas and tables - so the assistant knows what’s available
Describe table structure - columns, types, and nullability
Run read-only SQL - the assistant writes the query; Qora validates and executes it
Return results safely - capped row counts, no writes or schema changes
Only read-style queries are allowed
Connect with a read-only database user
Result size is capped
HTTP access can be limited to specific hosts
Tool | What it does |
| See the main areas of your data |
| See what tables exist |
| Understand what's inside a table |
| Run a validated read-only SELECT |
Setup - install, env, MCP clients, HTTP, Docker
Contributing - Dev Container, scripts, PR checklist
Get column names, data types, and nullability for a specific table. Call this before querying a table you haven't seen the schema for.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | Schema that owns the table | |
| table_name | Yes | Table or view name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the key behavioral trait of safety. The description adds no further behavioral disclosure such as error cases, authorization requirements, or performance characteristics, but for a simple read-only introspection tool this is an acceptable gap.
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 tightly written sentences: the first states the core operation and the second provides actionable timing guidance. There is no filler, repetition, or schema duplication.
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 low-complexity tool with fully documented parameters and a read-only annotation, this description is nearly complete. It could be slightly stronger with a note about error behavior or an example output, but nothing required for correct invocation is missing.
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 input schema provides 100% coverage with clear descriptions for both 'schema' and 'table_name'. The description adds no extra parameter-level meaning beyond the overall purpose, so it stays at the baseline since the schema carries the burden.
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 opens with a specific verb ('Get') and names the exact resource: column names, data types, and nullability for a table. This clearly distinguishes it from siblings like list_tables, list_schemas, and run_query, which are about enumeration or query execution.
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?
It explicitly tells the agent when to call this tool: 'before querying a table you haven't seen the schema for.' However, it does not mention when not to use it or contrast it with sibling tools, so it lacks full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List database schemas the agent can see (system schemas excluded). Call this first to discover which schemas exist, then list_tables / describe_table.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by disclosing that the result is filtered to schemas the agent can see and excludes system schemas, which goes beyond the annotation.
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 filler. The core purpose is front-loaded, and the usage guidance is packed into a short, actionable second sentence.
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 zero-parameter discovery tool, the description covers what it does, its filtering behavior, and how it fits into the workflow. No output schema is present, but the description sufficiently guides correct 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?
The tool has zero parameters, so the baseline is 4. The description adds meaning by clarifying which schemas are included (visible, non-system), which effectively defines the tool's scope in the absence of parameters.
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?
States a precise verb and resource: "List database schemas the agent can see." It also adds a clear scope qualifier ("system schemas excluded") that helps distinguish this from generic schema listing tools.
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?
Explicitly instructs the agent when to use this tool: "Call this first to discover which schemas exist." It also names the follow-up tools (list_tables / describe_table), giving clear sequencing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tables and views the agent can query. Optionally filter by schema. Always call this (or describe_table) before writing a query against an unfamiliar table.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Optional schema name. If omitted, lists tables across all non-system schemas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no further safety disclosure is needed. The description adds a behavioral scoping detail – it only lists tables and views the agent can query – which is valuable context. It does not mention return fields, but for a read-only listing tool this is a minor omission.
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?
Three short sentences with no filler: purpose, optional parameter, and usage guidance. Each sentence serves a distinct role and information is front-loaded, making it easy for an agent to parse quickly.
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 listing tool with one optional parameter and no output schema, the description covers when to use it and its scope. It does not describe the return fields (e.g., table name, schema, type), but given the tool's simplicity and read-only annotation, the gap is acceptable.
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 100%, so the parameter is fully documented in the schema. The description only repeats 'Optionally filter by schema' without adding format or default behavior beyond what the schema states. Baseline 3 applies.
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?
States a specific verb and resource: 'List tables and views the agent can query.' The phrase 'the agent can query' clarifies scope, and it is clearly distinct from sibling list_schemas (lists schemas) and describe_table (describes one 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?
Explicitly instructs when to call: 'Always call this (or describe_table) before writing a query against an unfamiliar table.' This provides a clear usage rule and names the alternative tool, leaving no ambiguity about when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a read-only SQL SELECT against Postgres. Only SELECT is permitted — writes, DDL, and multi-statement queries are rejected. Results capped at 1000 rows and returned as JSON ({ columns, rowCount, rows }). Prefer GROUP BY / aggregation over raw dumps. Always qualify table names with schema, e.g. SELECT * FROM analytics.orders. Discover schemas/tables via list_schemas, list_tables, and describe_table first.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Read-only SELECT statement to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true, the description adds substantial behavioral detail: enforced SELECT-only policy, rejection of DDL and multi-statement queries, 1000-row cap, and JSON result shape with columns, rowCount, and rows. This exceeds what annotations alone convey.
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 appropriately sized, front-loaded with the core purpose, and every sentence provides useful guidance: restrictions, output format, query style, and discovery workflow.
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 single-parameter tool with no output schema, the description fully covers input expectations, constraints, output shape, and how to discover context before querying. Nothing essential is missing.
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 100% for the single sql parameter, establishing a baseline of 3. The description adds meaningful guidance beyond the schema by giving an example of schema-qualified queries and explaining result limits and aggregation preferences.
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?
States a specific verb and resource: 'Run a read-only SQL SELECT against Postgres.' This clearly distinguishes the tool from metadata-only siblings like list_schemas, list_tables, and 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 explicitly states when to use the tool (read-only SELECT) and what is rejected (writes, DDL, multi-statement queries). It also advises qualifying table names with schema and discovering schemas/tables via sibling tools first, leaving no ambiguity about usage.
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.
v1.0.0describe_tablelist_schemaslist_tablesrun_queryScored across 4 tools
Each tool has a clearly distinct purpose: discovering schemas, listing tables, describing table schemas, and executing queries. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern (list_schemas, list_tables, describe_table, run_query), making the naming predictable and clean.
With 4 tools, the set is well-scoped for a read-only database exploration and querying server. Each tool is necessary and sufficient for the core workflow.
The surface covers the full discovery-to-query lifecycle: schema discovery, table listing, schema introspection, and read-only query execution. No essential operations are missing for the stated purpose.
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
