Skip to main content
Glama

Search a table's rows

search_table
Read-onlyIdempotent

Ranked search over one public table's rows, the same search its dataset page runs: words, prefixes, typos and spelling correction, served from the table's search package. NOT a catalogue search (search_datasets finds datasets) and not SQL. Example: {"table_id": "0f2f...", "query": "blade runner 1982"}. settled defaults to true (a finished query, which may be planned by a model); send settled: false for a fast keystroke answer planned by the parser alone. page_size is 1-100 (default 20). columns is a subset of the table's search display columns (default all of them). Returns {rows: [{row_id, fields}], plan, planner, retrieval, next_cursor, count, package: {generation_id, package_digest}, table_version_id, timings}. For the next page send the same query with the answer's plan and next_cursor. like: a row_id from an answer finds the rows most like that row (more like this; query, when not empty, is a topic beside it), on a table whose search has meaning vectors. mode (first page only): auto (default) lets the planner choose; meaning ranks by meaning alone; image finds rows whose pictures look like the query (posters showing a red sky over a city); emoji searches by the query's emojis. A table whose search cannot run a mode answers invalid_plan. count: true also asks for the exact number of matching rows; count is null when the table cannot count yet. corrected, when present, is the spelling the search used. A table with no ready search answers search_unavailable with a reason: preparing (ask again shortly), not_public (another workspace's private or link-shared table; your own workspace's tables are searchable whatever their visibility) or the package's state. To filter, sort or aggregate, use query_table. Requires an mr_use_ workspace key (Authorization: Bearer) or an OAuth connection, like query_table, and counts against the same allowance. Cite the package generation and digest. Reads past the free sample (the first 500 rows of a table in stored order) count against the workspace's shared free monthly allowance of 100,000 rows and 1,000 queries (the workspace of the key or grant in use) unless it is subscribed. A download counts the rows it contains, plus one query per table. At the limit the tool answers usage_limit_exceeded with the reset time and an upgrade URL.

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_id": "<table_id>",
      "query": "<query>"
    },
    "name": "search_table"
  }
}

Input Schema

NameRequiredDescriptionDefault
likeNo
modeNo
planNo
countNo
queryYes
cursorNo
columnsNo
settledNo
table_idYes
page_sizeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / like
      Added value: +{
      +  "maximum": 9007199254740991,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / mode
      Added value: +{
      +  "enum": [
      +    "auto",
      +    "meaning",
      +    "image",
      +    "emoji"
      +  ],
      +  "type": "string"
      +}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Far beyond the annotations: discloses pagination via plan+next_cursor, error contract (search_unavailable with preparing/not_public reasons, invalid_plan, usage_limit_exceeded with reset time), auth requirement (mr_use_ key or OAuth), billing/allowance rules, and citation obligation. This is exactly the behavioral context annotations can't carry.

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?

Front-loaded with purpose and tightly packed with no filler, but it reads as a long dense run-on where error, billing, and mode details interleave. Information earns its place, yet a bit of structural separation would improve scanability.

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?

No output schema exists, but the description fully specifies the return shape (rows/plan/planner/retrieval/next_cursor/count/package/table_version_id/timings) plus error states and auth, so an agent has everything needed to call and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry all meaning, and it does: settled (finished vs keystroke), page_size range/default, columns default, like as more-like-this, mode's four values, count semantics, and plan/cursor pagination. Every one of the 10 params gets semantic depth the bare schema lacks.

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?

Specific verb and resource ('Ranked search over one public table's rows') with the search behavior spelled out (words, prefixes, typos, spelling correction). It explicitly distinguishes itself from both search_datasets (catalogue) and query_table (SQL), so an agent can route without opening schemas.

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?

Explicitly states when not to use it ('NOT a catalogue search... not SQL') and names the correct alternative ('To filter, sort or aggregate, use query_table'). Includes mode-selection guidance and next-page mechanics, leaving little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources