drizzle-mcp

Overview Schema Source Related Servers Discussions Admin

Browse rows

browse

Read-only

Reads rows from a Drizzle table with column selection, filtering, sorting, pagination, and related-row includes, returning TypeScript-keyed rows plus total matches.

Instructions

Reads rows from a table, like Drizzle Studio: pick columns, filter, sort, page, and include related rows through the schema's relations. Returns rows keyed by TypeScript property, plus the total matching.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "table": "<table>"
    },
    "name": "browse"
  }
}

Input Schema

Name	Required	Description
`with`	No	Related rows to include, by relation name: {"author": true} or {"comments": {"limit": 5, "columns": ["body"], "with": {"author": true}}}. Many-relations return 10 rows unless you set a limit.
`limit`	No	Rows to return, up to 100.
`table`	Yes	The table: its TypeScript export or SQL name.
`where`	No	Conditions that must all hold, keyed by column (TypeScript key or SQL name). A plain value means equals: {"published": true}. Operators: {"createdAt": {"gte": "2026-01-01"}}, {"title": {"ilike": "%drizzle%"}}, {"id": {"in": [1, 2]}}, {"deletedAt": {"isNull": true}}. Use {"or": [{...}, {...}]} for alternatives.
`offset`	No	Rows to skip, to page through the results.
`columns`	No	Only these columns.
`orderBy`	No	Sort order. Defaults to the primary key.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value beyond them by disclosing the return contract ('rows keyed by TypeScript property, plus the total matching'), which matters since there is no output schema. It does not mention cost, row-count caps, or performance behavior for deep relations.

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?

Two tightly written sentences, with the core action and capability list front-loaded before the return behavior. The 'like Drizzle Studio' analogy is compact but only pays off for an agent familiar with that tool.

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 7-parameter read tool with annotations and no output schema, the description covers action, capability surface, and return shape adequately. Remaining gaps — relation cost, default ordering rationale, and paging interaction — are mostly handled by the schema, so the definition is close to 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?

Schema description coverage is 100% and the schema's own parameter descriptions already carry examples for 'where' operators, 'with' nesting, and limits. The description only loosely maps its verbs to parameter families (pick columns, filter, sort, page, include related rows), adding little semantics beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('Reads rows from a table') and enumerates the supported operations (columns, filter, sort, page, relations) plus the return shape. It does not differentiate itself from siblings such as 'query' or 'count', so an agent must infer that this is the structured/ORM-style read path rather than raw SQL or aggregation.

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?

Usage is implied by the 'like Drizzle Studio' framing and the enumeration of filtering/sorting/paging features, which suggests table-shaped reads. However, there is no explicit statement of when to choose this over 'query', 'count', or 'explain', and no mention of prerequisites or when-not to use it.

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

Deploy Server