Skip to main content
Glama

read_data

Read-onlyIdempotent

Read-only queries on the open spreadsheet. No data is modified. Safe to auto-approve. Call as {"action": "", "params": {...}} — per-action params are listed in the Action Reference below.

Special actions (not shown in the action enum): • batch — {"action": "batch", "params": {"actions": [{"action": "", "params": {...}}, ...]}}. Runs reads in parallel; individual failures are reported per-entry without short-circuiting. • context — {"action": "context", "params": {"topic": ""}} or {"action": "context", "params": {"action": ""}}. Returns deeper docs for a topic or a single action's signature. Plural "topics" / "actions" arrays are also accepted and may be combined. Topics: python, javascript, formula, connection, validation, a1, quadratic, chart, pivot_table.

Action Reference

• get_cell_data(selection, page?, sheet_name?) — Returns cell values for a selection in A1 notation. Supports comma-separated ranges to fetch multiple areas in ONE call, including across different sheets. Examples: "A1:B10, D1:E10", "TableName, OtherTable", "'Sheet1'!A1:B10, 'Sheet2'!C1:D10". Table names are globally unique so they work without sheet prefixes. For cell ranges on other sheets use 'SheetName'!Range. Only use when you need the full dataset (aggregations, lookups, analysis). The file summary already includes sample rows. Results may be paginated — use page (0-based) for additional pages. • has_cell_data(selection, sheet_name?) — Check if any cells in a selection have data. Returns true if ANY cell contains data. Use before creating/moving tables or code to avoid spill errors. All ranges MUST be on the same sheet. • get_code_cell_value(code_cell_position?, code_cell_name?, sheet_name?) — Get full code from an existing Python, JavaScript, or connection code cell. Do NOT use for formula cells — formulas are already in get_cell_data results and the file summary. • get_text_formats(selection, page?, sheet_name?) — Get text formatting info. Use table column references for tables ("Table_Name[Column Name]"). Results may be paginated. • get_validations(sheet_name?) — Get all validations in a sheet. • get_conditional_formats(sheet_name) — Get all conditional formatting rules. Use to check existing rules before creating/updating/deleting. • text_search(query, case_sensitive?, whole_cell?, search_code?, regex?, sheet_name?) — Search for text in cell outputs. Supports regex when enabled (e.g., "\d+", "^hello", "foo|bar"). Searches cell outputs only, not code. Booleans default false. • get_sheet_info() — List all sheets and names. • get_spreadsheet_context(sheet_name?, include_errors?) — Full context snapshot of the file. • read_data(selection, sheet_name?, max_rows?) — Read cell data as compact CSV. Auto-tiers: returns all rows for small/medium data (<5000 rows), head+tail preview for large data. Preferred over get_cell_data for most reads. • outline(sheet_name?) — Structural map of the file: sheets, bounds, tables, code cells, charts, connections, errors. Use to understand file layout before reading data. • dependencies(position, sheet_name?, direction?) — Trace cell dependencies. direction: "forward" (what this cell reads), "reverse" (what depends on this cell), or "both" (default). • export_pdf(options?) — Export the file as a PDF with Excel-parity print semantics. Returns {mime_type, size_bytes, data_base64}. options is a camelCase object: {sheetIds?: [id], fileName?, pageSetup?: {paperSize ("letter"|"legal"|"tabloid"|"a3"|"a4"|"a5"|...), orientation ("portrait"|"landscape"), margins {left,right,top,bottom,header,footer} (inches), scaling ({type:"zoom",percent} or {type:"fitTo",width?,height?}), pageOrder ("downThenOver"|"overThenDown"), centerHorizontally?, centerVertically?, printGridlines?, printHeadings?, header/footer {odd:{left,center,right}, even?, first?} with Excel codes (&P page, &N total, &D date, &T time, &F file, &A sheet, &B bold)}, sheetOptions?: {"": {pageSetup?, printArea? ("A1:F20"), repeatRows? ([1,2]), repeatCols?, rowBreaks?, colBreaks?}}}. Omit options for sensible defaults (letter portrait, 100% zoom, all sheets). • list_connections(team_uuid?) — List all database connections in a team (PostgreSQL, MySQL, MS SQL, Snowflake, BigQuery, Mixpanel, Google Analytics, Plaid, etc.). Returns each connection's uuid, name, and type. team_uuid is optional — if omitted, the user's only team is used; multi-team users must pass it. Call this BEFORE get_database_schemas or set_sql_code_cell_value to discover the connection_ids and connection types you need. • get_database_schemas(connection_ids, connection_type, team_uuid) — Get table/column schemas for database connections. Always call before writing SQL. Get connection_ids from list_connections. connection_type: POSTGRES, MYSQL, MSSQL, SNOWFLAKE, BIGQUERY, COCKROACHDB, etc. • list_agent_connections(team_uuid?) — List the team's ready Agent Connections (third-party REST API bindings). Returns each connection's uuid, name, service, base URL, auth pattern, and {{SECRET_NAME}} references to use in fetch code. team_uuid is optional — if omitted, the user's only team is used; multi-team users must pass it. Reference secrets via {{SECRET_NAME}} in Python/JavaScript fetch code; the connection proxy substitutes team secret values at request time. • inspect_agent_connection(connection_id, team_uuid?) — Get the full schema (resources, endpoints, fields, docs URLs) and plan for one ready Agent Connection by uuid (from list_agent_connections). Call BEFORE writing fetch code against a connection so you don't guess at endpoints. team_uuid is optional with the same single-team fallback as list_agent_connections.

Batch: • batch(actions) — actions: [{action, params}]. Runs reads in parallel through this same tool; per-entry failures are reported in the result without short-circuiting the batch. action may be any name from this reference. Nested context items are allowed and returned alongside the reads.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: get_cell_data, has_cell_data, get_code_cell_value, get_text_formats, get_validations, get_conditional_formats, text_search, get_sheet_info, get_spreadsheet_context, read_data, outline, dependencies, export_pdf, get_database_schemas, list_connections, list_agent_connections, inspect_agent_connection, or batch
paramsNoParameters for the action (see tool description). For batch: {actions: [{action, params}, ...]}

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / action / description
      Previous value: -"Action to perform: get_cell_data, has_cell_data, get_code_cell_value, get_text_formats, get_validations, get_conditional_formats, text_search, get_sheet_info, get_spreadsheet_context, read_data, outline, dependencies, get_database_schemas, list_connections, list_agent_connections, inspect_agent_connection, or batch"New value: +"Action to perform: get_cell_data, has_cell_data, get_code_cell_value, get_text_formats, get_validations, get_conditional_formats, text_search, get_sheet_info, get_spreadsheet_context, read_data, outline, dependencies, export_pdf, get_database_schemas, list_connections, list_agent_connections, inspect_agent_connection, or batch"
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint/idempotentHint annotations, the description adds 'Safe to auto-approve', explains batch per-entry failure without short-circuiting, pagination for large results, team_uuid fallback behavior for single-team users, and secret substitution via {{SECRET_NAME}}. These are meaningful operational disclosures.

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?

Extremely long but well-organized into sections (general, special actions, action reference, batch). Each action entry is concise and front-loaded with behavior. Some repetition (e.g., team_uuid optional note) but every sentence adds necessary operational detail.

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?

Given the tool is a dispatcher for 18+ sub-actions with no output schema, the description is remarkably complete: it covers return shapes (e.g., list_connections returns uuid/name/type, export_pdf returns mime_type/size_bytes/data_base64), pagination, error handling, prerequisites, and optional parameter behavior. Nothing critical is missing.

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 only has 'action' and 'params' with generic descriptions. The description provides full parameter semantics for every sub-action, including A1 notation selection formats, optional parameters with defaults, regex examples, output formats for export_pdf, and connection types. This compensates entirely for schema sparsity.

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?

Description states 'Read-only queries on the open spreadsheet' with explicit 'No data is modified', clearly distinguishing from write_data sibling. It enumerates a full action reference, making the dispatcher role unambiguous. The verb+resource pairing is specific and actionable.

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?

Provides explicit when-to-use guidance: 'Use before creating/moving tables or code to avoid spill errors', 'Call this BEFORE get_database_schemas or set_sql_code_cell_value', 'Preferred over get_cell_data for most reads', and 'Do NOT use for formula cells'. Also includes call format and special batch/context usage.

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.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a clearly distinct concern: auth handles session lifecycle, files_read lists metadata, files_write manages file sessions, read_data queries spreadsheet contents, and write_data modifies them. No two tools have overlapping purposes.

Naming Consistency2/5

Tool names follow inconsistent conventions: 'auth' is a bare noun, 'files_read' and 'files_write' use noun_verb order, while 'read_data' and 'write_data' use verb_noun order. This mixed pattern makes it harder to predict related tool names.

Tool Count5/5

Five top-level tools form an elegant umbrella structure that groups dozens of actions into meaningful categories. The count is ideal for guiding an agent to the correct tool without overwhelming it.

Completeness4/5

The surface covers the full spreadsheet lifecycle: authentication, file management, cell/range operations, formulas, code, SQL, formatting, sheets, tables, charts, pivot tables, validation, and history. Missing file deletion/rename and some advanced sheet management are minor gaps that can be worked around.