Skip to main content
Glama

search_columns

Find columns across every table using filters such as name, type, sensitivity, or inferred patterns. Use when the table holding a fact is unknown.

Instructions

Find columns across every table - the first call when the table holding a fact is not yet known. Filters, all optional and ANDed: a name glob, a text search over column names and their notes, and classification/sql_type/sensitivity/looks_like/redacted globs and a candidate_key match - for example every column holding an email address (looks_like: email) or contact details (sensitivity: contact). Read a table found this way with get_table_context; list tables rather than columns with list_tables. A match on a table read in part carries its scope block with rows_scanned/row_count, so a caller can tell a scanned-set number or key from a table-wide one; a match carrying a looks_like verdict carries the sampled/matched draw behind it, since a verdict from two values reads identically to one from ten thousand otherwise. A match carries sensitivity/redacted/candidate_key (and candidate_key_exception where the ratio falls short of 1.0) whenever the column does, so filtering on any of them returns the matched category, not just a bare column name. Paged: every reply carries the total matched, and next_cursor while more remain. A result carries unreadable_tables only when a table's own statistics or annotations failed to parse, on its first page: a statistics failure drops that table's columns from matches entirely; an annotations-only failure still returns them, without the annotation. A looks_like search also carries switched_off_tables on its first page, naming each table whose looks_like detection was switched off, where a non-match is not a finding.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoCase-insensitive substring matched against the column name, the note people wrote on it and its per-value notes - words, not meaning. A match found through per-value notes carries them as `value_notes`
cursorNo`next_cursor` from this call's previous page; omit for the first page
patternNofnmatch glob over column names, and over a part as `<column><path>` (`items[*].sku`); optional - omit to filter by the other predicates alone
redactedNofnmatch glob against the column's redacted marker (drop, hash, mask)
sql_typeNofnmatch glob against the column's sql_type
connectionNoWhich database to read, by connection name; needed only when the server serves several, and the error for a missing one lists them. Omit it for the server's default
looks_likeNofnmatch glob against inferred.looks_like (base64, bic, card_number, content_type, country_code, currency_code, ean, email, filename, gif, gzip, hex, iban, imei, ip, isbn, iso8601_date, iso8601_datetime, iso8601_duration, jpeg, json, jwt, latlon, mac_address, numeric_string, path, pdf, phone, png, postal_code, prose, semver, timezone, url, urn, uuid, vin, zip)
sensitivityNofnmatch glob against inferred.sensitivity (contact, credential, date_of_birth, demographic, employment, financial_account, geolocation, health, national_id, online_identifier, personal_name, postal_address) - a glob of '*' sweeps every column carrying any detection. A detection, never a verdict; its absence on a column is not an assertion that the column is safe
candidate_keyNoExact match against inferred.candidate_key
classificationNofnmatch glob against the column's classification (binary, boolean, categorical, composite, foreign_key_candidate, json, numeric, spatial, temporal, text, unsupported, vector)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden — and it delivers: ANDed filter semantics, pagination (total, next_cursor), partial-scan scope blocks, sampling behind looks_like verdicts, and two distinct failure surfaces (unreadable_tables, switched_off_tables) with the differing consequences of statistics vs annotation failures. This is unusually rich behavioral context for a read tool.

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?

Well front-loaded — purpose, then routing, then filter semantics, then return/paging behavior. It is dense and long, and the closing sentences on unreadable_tables/switched_off_tables are heavy, but with no output schema the detail is load-bearing rather than padding.

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?

With no output schema and 10 optional parameters, the description compensates fully: it describes the shape of a match, echoed classification fields, candidate_key_exception, page metadata, and conditional error fields. An agent has everything needed to call it and interpret results.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond it: it explains that filters are optional and ANDed, gives concrete combined examples (looks_like: email, sensitivity: contact), and clarifies that filtered fields are echoed back on matches.

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?

States a precise verb+resource ('Find columns across every table') and immediately frames the discovery scenario ('the first call when the table holding a fact is not yet known'). It explicitly distinguishes itself from siblings that could be confused with it.

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?

Gives explicit when-to-use ('first call when the table holding a fact is not yet known') and names both alternatives with their selecting conditions: get_table_context to read a found table, list_tables when you want tables rather than columns. No inference required.

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