Skip to main content
Glama

Find First Row

db_find_first
Read-onlyIdempotent

Retrieves a single database row matching a JSON filter. Returns the first match as an object, or null when none exists, making single-row lookups clear.

Instructions

Finds a single row matching the given filter. Returns the first matching row or null if no rows match. Use this instead of db_find_many when you expect exactly one result and want a single object rather than an array. Sensitive columns are automatically redacted.

When to use:

  • "Get user with ID 42", "Find the order with this tracking number"

  • Lookups by unique identifier (primary key or unique constraint)

  • When you need exactly one row, not a list

Parameter guidance:

  • where: JSON filter object (required). Must be specific enough to target one row. Example: {"id": 42} or {"email": "user@example.com"}

  • select: optional JSON array of column names to return

Behavioral notes:

  • Returns a single JSON object, not an array.

  • Returns null (not an error) when no row matches the filter.

  • For queries that should return multiple rows, use db_find_many instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tableYesName of the table to query
whereYesJSON filter object to find a single row
selectNo
databaseNoName of the database to query (from pgautopilot.json). Omit to use the current default database.
Install Server

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable context beyond annotations: sensitive columns are automatically redacted, null is returned rather than an error, and the result is a single object. This is strong but not exhaustive—the meaning of 'first' row is not clarified with respect to ordering.

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 well-structured with clear sections for usage, parameters, and behavior, and it front-loads the core purpose. It is slightly repetitive—'use db_find_many instead' appears in both the opening and the behavioral notes—but this redundancy is minor and aids routing.

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?

The description covers return type, null behavior, sensitive column redaction, parameter guidance, and sibling differentiation, which is substantial given no output schema. The only notable omission is clarifying whether 'first' implies a defined ordering or is database-dependent, which could matter for exact-result expectations.

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?

With 75% schema coverage, the schema documents table, where, and database, but select lacks a description. The description compensates by explaining where as a JSON filter object with concrete examples, emphasizing specificity, and defining select as an optional JSON array of column names.

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 a specific verb plus resource: 'Finds a single row matching the given filter', and clearly distinguishes itself from db_find_many by emphasizing a single object rather than an array. It also states the null return case, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use this tool 'instead of db_find_many when you expect exactly one result' and provides concrete scenarios like unique identifier lookups. It also repeats the exclusion in the behavioral notes, so an agent has clear routing guidance.

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

Other Tools

Latest Blog Posts

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/cyberreinxy/pgautopilot'

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