Quadratic
Server Details
AI access to Quadratic spreadsheets: open files, run Python/SQL, query connected databases.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 5 of 5 tools scored.
The five tools (auth, files_read, files_write, read_data, write_data) have clearly distinct purposes. Even the numerous sub-actions are well-grouped, leaving no ambiguity about which tool to use for a given task.
All tool names follow a consistent verb_noun pattern (auth, files_read, files_write, read_data, write_data). Sub-actions also adhere to standard naming conventions like list_, get_, set_, etc., ensuring predictability.
With 5 top-level tools, the surface is well-scoped for a spreadsheet MCP server. It covers authentication, file management, and data read/write operations without being overly granular or sparse.
The tool set provides extensive coverage for spreadsheet operations including cell editing, formulas, code, formatting, tables, validation, and import. A notable gap is the lack of a delete file operation, but core workflows are fully supported.
Available Tools
5 toolsauthADestructiveInspect
Authenticate the MCP session with Quadratic.
Actions: • login() — Start an OAuth device authorization flow. Returns a URL the user must open in a browser to authorize. The flow is completed by confirm_login. • confirm_login(device_code) — Complete an in-progress login by polling for user authorization. If the response indicates the user has not yet authorized, this action can be called again with the same device_code to continue polling. • set_token(token, email?) — Set a JWT directly (used when the OAuth device flow is not available). • logout() — Clear saved authentication for the current session.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: login, confirm_login, set_token, or logout | |
| params | No | Parameters for the action (see tool description) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations: login returns URL, confirm_login can be polled repeatedly, set_token sets JWT, logout clears auth. Annotations indicate mutation and destructiveness. Could be more specific about side effects of logout (e.g., token invalidation), but overall informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a bullet list of actions, each one sentence. No redundant text. Front-loaded with overall purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description must clarify return values. It mentions login returns a URL, but does not specify response structures for other actions (e.g., confirm_login status, set_token success). Polling behavior is noted but error handling or timeout details are missing. Adequate but not fully complete for a multi-step auth flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage but the 'params' property is vague ('see tool description'). The description enriches it by specifying required parameters per action (e.g., device_code for confirm_login, token/email for set_token), which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: authenticating the MCP session with Quadratic. It enumerates specific actions (login, confirm_login, set_token, logout) with brief explanations, making it distinct from sibling tools that focus on file and data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each action, including the polling behavior for confirm_login and the fallback set_token. However, it does not explicitly state when not to use the tool or mention alternatives, though sibling tools are unrelated, reducing the need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
files_readARead-onlyIdempotentInspect
Read-only file metadata operations on Quadratic files the user has access to. No data is modified. Requires authentication.
Actions: • list_files() — List all accessible files. • get_file_info(file_id) — Get metadata for a single file.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: list_files or get_file_info | |
| params | No | Parameters for the action (see tool description) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'Requires authentication' beyond annotations which already include readOnlyHint, openWorldHint, idempotentHint. Aligns with annotations and adds valuable context about authentication need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient and front-loaded: first sentence states purpose, then a short bullet list covers all actions. Every sentence is necessary; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata tool with no output schema, the description fully covers what actions are available, their scope (user's accessible files), and authentication requirements. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description elaborates on actions and their parameters (e.g., file_id for get_file_info), adding meaning beyond schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Read-only file metadata operations' and lists two specific actions (list_files, get_file_info). Distinguishes from sibling tools like files_write and read_data by specifying scope and read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: read-only, metadata-only, requires authentication. Implicitly differentiates from read_data (which likely reads file content) but does not explicitly state when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
files_writeADestructiveInspect
File management operations that create or modify state: create a new file, open an existing file to start an editing session, or close a session. Requires authentication.
Actions: • open_file(file_id?, file_name?) — Open a file by UUID or name and start an editing session. Returns the file's web URL. • create_file(file_name, team_uuid?) — Create a new blank spreadsheet. If team_uuid is omitted, the user's first team is used. Returns the new file's UUID and web URL; the file must be opened with open_file before it can be edited. • close_file(file_id) — Close an active editing session.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: open_file, create_file, or close_file | |
| params | No | Parameters for the action (see tool description) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Matches annotations (destructiveHint=true, readOnlyHint=false). Discloses authentication needs, that create_file returns UUID/URL and requires subsequent open_file, and close_file ends session. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then bulleted actions. Every sentence contributes new information. No fluff. Clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all actions (create, open, close), explains return values for create and open, workflow order (create then open before edit). No output schema needed as descriptions suffice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage but is minimal (action string, generic params). Description adds meaning by detailing per-action parameters: open_file(file_id, file_name), create_file(file_name, team_uuid), close_file(file_id). Adds return values and workflow dependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it handles file management operations that create or modify state: create, open, close files. Distinguishes from sibling 'files_read' by focusing on write operations. Lists specific actions with behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires authentication. Explains when to use each action (e.g., open before edit, close to end session). Does not explicitly exclude scenarios or compare with siblings like write_data, but context implies file-level operations vs cell-level data operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_dataARead-onlyIdempotentInspect
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.
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).
• 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.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 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 | |
| params | No | Parameters for the action (see tool description). For batch: {actions: [{action, params}, ...]} |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the tool is read-only and safe to auto-approve, adding behavioral context beyond the annotations (readOnlyHint, idempotentHint). It also explains special behaviors like batch execution and the context action for documentation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for special actions and an action reference, but it is very long. While every action likely needs explanation, the overall length may hinder quick scanning. Some redundancy (e.g., repeating the file summary mention) could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all 16 actions, explains batch and context, provides pagination details, examples, and use-case guidance for several sub-actions. Given the complexity and lack of output schema, it is remarkably complete, leaving minimal gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only two generic parameters (action, params), and the description compensates fully by detailing each valid action and its specific parameters with examples. This adds tremendous semantic value, making the otherwise opaque params field understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read-only queries on the open spreadsheet' and lists all supported read actions, establishing the tool's scope. However, as a dispatcher for many sub-actions, the purpose is broad and does not explicitly differentiate from sibling tools like files_read or auth, leaving some ambiguity about when to use this tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use each sub-action (e.g., 'Use before creating/moving tables' for has_cell_data), but does not offer guidance on when to choose this tool over its siblings. It implicitly assumes the agent knows to use this for spreadsheet reads, but lacks explicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_dataADestructiveInspect
Write operations on the open spreadsheet. Call as {"action": "", "params": {...}} — per-action params are listed in the Action Reference below. Numbers, booleans, and nulls in cell values are coerced to strings.
Special actions (not shown in the action enum): • batch — {"action": "batch", "params": {"actions": [{"action": "", "params": {...}}, ...]}}. Runs writes sequentially; errors short-circuit the batch. • 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.
Action Reference
Cell Data: • set_cell_values(top_left_position, cell_values, sheet_name?) — Sets cell values as a 2D string array (first row = headers). top_left_position: single cell in A1 notation. Don't place over existing data unless requested. Values replace existing content; use empty string to clear. For merged cells, place at the anchor (top-left) cell. Prefer this over add_data_table unless data is clearly tabular. Don't use for formulas or code. • delete_cells(selection, sheet_name?) — Delete cell values in a selection (A1 notation). Don't delete cells referenced by code cells unless explicitly asked. To delete table columns: "TableName[Column Name]". To delete tables: "TableName". • move_cells(source_selection_rect, target_top_left_position, sheet_name?) — Move a rectangular block of cells. Target is the top-left corner (single cell). For spilled code cells, move just the anchor cell. • add_data_table(sheet_name, top_left_position, table_name, table_data) — Adds a data table. First row of table_data is headers. Leave 2 rows below and 2 columns right as spacing. All rows must have equal length (use empty strings for missing values). To convert existing data, use convert_to_table instead. To delete a table, use set_cell_values with empty string at the anchor. Don't add formulas or code to data tables.
Code: • set_code_cell_value(code_cell_position, code_cell_language, code_cell_name, code_string, sheet_name?) — Sets and runs a Python or JavaScript code cell. Use for complex tasks (data transforms, ML, correlations, charts). For simple tasks use set_formula_cell_value. For static data use set_cell_values. For SQL use set_sql_code_cell_value. IMPORTANT: Always reference sheet data with q.cells() — never hardcode data values. For charts, use Plotly ONLY (import plotly.express or plotly.graph_objects). Do NOT use Matplotlib/Seaborn. Name the output (no spaces/special chars, _ allowed). Placement: Estimate output size before placing. Charts default to 7 wide x 23 tall cells. Cell must be empty (avoids spill error). Leave one extra column/row gap between the code cell and nearest content. Empty sheet → A1. • set_formula_cell_value(formulas) — formulas: [{code_cell_position, formula_string, sheet_name?}]. Don't prefix formulas with =. code_cell_position can be a single cell ("A1"), range ("A1:A10"), or collection ("A1,A2:B2"). Cell references adjust relatively (like copy-paste). Use $ for absolute references ($A$1). Place near referenced data, no extra spacing needed. Aggregations go directly below or beside data. • rerun_code(sheet_name?, selection?) — Re-run code cells. Do NOT call after set_code_cell_value, set_formula_cell_value, or set_sql_code_cell_value — those already run automatically. Only use to refresh unchanged code (e.g., external data). • set_sql_code_cell_value(code_cell_position, code_cell_name, connection_kind, sql_code_string, connection_id, sheet_name?) — Sets and runs a SQL connection code cell. connection_kind: POSTGRES, MYSQL, MSSQL, SNOWFLAKE, BIGQUERY, COCKROACHDB, MARIADB, SUPABASE, NEON, MIXPANEL, GOOGLE_ANALYTICS, PLAID, QUICKBOOKS. Always call get_database_schemas before writing SQL. Cell must be empty. Empty sheet → A1.
Import: • import_file(file_name, file_data, sheet_name?, insert_at?) — Import CSV/Excel/Parquet. file_data: base64-encoded. Extension determines format (.csv, .xlsx/.xls, .parquet/.parq/.pqt). To create a new file from an import, call files create_file first, then import_file.
Formatting: • set_text_formats(formats) — formats array: [{selection, bold?, italic?, underline?, strike_through?, text_color?, fill_color?, align?, vertical_align?, wrap?, font_size?, number_type?, currency_symbol?, numeric_decimals?, numeric_commas?, date_time?, sheet_name?}]. For table columns use table references ("Table_Name[Column Name]") instead of A1 ranges. Colors: hex ("#FF0000"), empty string to remove. align: "left"/"center"/"right". vertical_align: "top"/"middle"/"bottom". wrap: "wrap"/"clip"/"overflow". number_type: "number"/"currency"/"percentage"/"exponential" (currency requires currency_symbol, e.g. "$"). numeric_decimals: integer >= 0, number of decimal places to display (e.g. "format percents as 2 decimals" → 2). Percentages: .01 → 1%, 1 → 100%. date_time: chrono format e.g. "%Y-%m-%d". font_size: points (default 10). Set to null to clear any format. • set_borders(borders) — borders: [{selection, border_selection, color, line, sheet_name?}]. border_selection: all/inner/outer/horizontal/vertical/left/top/right/bottom/clear. line: line1 (thin)/line2 (medium)/line3 (thick)/dotted/dashed/double/clear. color: CSS color string. • merge_cells(selection, sheet_name?) — Merge a range of cells (e.g. A1:D1). All values except top-left are cleared. • unmerge_cells(selection, sheet_name?) — Unmerge merged cells overlapping the selection.
Sheets: • add_sheet(sheet_name, insert_before_sheet_name?) — Sheet names: unique, max 31 chars, no / \ ? * : [ ] • duplicate_sheet(sheet_name_to_duplicate, name_of_new_sheet) • rename_sheet(sheet_name, new_name) • delete_sheet(sheet_name) • move_sheet(sheet_name, insert_before_sheet_name?) • color_sheets(sheet_names_to_color) — [{sheet_name, color}]. color: CSS color string.
Tables: • convert_to_table(selection, table_name, first_row_is_column_names, sheet_name?) — Convert existing cell data to a data table. Selection must NOT contain code cells or existing tables. Table name row is added above, pushing data down by one row. • table_meta(table_location, new_table_name?, show_name?, show_columns?, alternating_row_colors?, first_row_is_column_names?, sheet_name?) — Set table metadata. table_location: anchor cell (top-left, e.g. A5). • table_column_settings(table_location, column_names, sheet_name?) — column_names: [{old_name, new_name, show}]. Only include columns to change. To delete columns use delete_cells with "TableName[Column Name]".
Layout: • resize_columns(selection, size, sheet_name?) — size: "auto" (fit content), "default", or pixels (20-2000). • resize_rows(selection, size, sheet_name?) — size: "auto", "default", or pixels (10-2000). • set_default_column_width(size, sheet_name?) — size in pixels (20-2000, default 100). • set_default_row_height(size, sheet_name?) — size in pixels (10-2000, default 21). • insert_columns(column, right, count, sheet_name?) — column: letter (e.g. "C"). right: true=insert right, false=insert left. • insert_rows(row, below, count, sheet_name?) — row: number. below: true=insert below, false=insert above. • delete_columns(columns, sheet_name?) — columns: array of letters (e.g. ["A", "C"]). • delete_rows(rows, sheet_name?) — rows: array of numbers (e.g. [1, 5, 10]).
Validation: • add_logical_validation(selection, show_checkbox?, ignore_blank?, sheet_name?) — True/false validation with optional checkbox. • add_list_validation(selection, list_source_list?, list_source_selection?, drop_down?, ignore_blank?, sheet_name?) — list_source_list: comma-separated values ("Item 1, Item 2"). list_source_selection: A1 cell reference. Use one, not both. • remove_validation(selection, sheet_name?) — Remove all validations from the selection.
Conditional Formatting: • update_conditional_formats(sheet_name, rules) — rules: [{action, id?, selection?, type?, rule?, bold?, italic?, underline?, strike_through?, text_color?, fill_color?, apply_to_empty?, color_scale_thresholds?, auto_contrast_text?}]. action: "create"/"update"/"delete". type: "formula" (apply styles when formula is true) or "color_scale" (gradient colors). For formula type: rule examples: "A1>100", "ISBLANK(A1)", "AND(A1>=5,A1<=10)". For color_scale: thresholds: [{value_type: "min"/"max"/"number"/"percent"/"percentile", value, color}]. For table columns use table references instead of A1 ranges. For delete: only id required.
History: • undo(count?) — Default 1. • redo(count?) — Default 1.
Batch:
• batch(actions) — actions: [{action, params}]. Runs writes sequentially through this same tool; errors short-circuit the batch. action may be any name from this reference. Nested context items are allowed and returned alongside the writes.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: set_cell_values, delete_cells, move_cells, add_data_table, set_code_cell_value, set_formula_cell_value, rerun_code, set_text_formats, set_borders, merge_cells, unmerge_cells, add_sheet, duplicate_sheet, rename_sheet, delete_sheet, move_sheet, color_sheets, convert_to_table, table_meta, table_column_settings, resize_columns, resize_rows, set_default_column_width, set_default_row_height, insert_columns, insert_rows, delete_columns, delete_rows, add_logical_validation, add_list_validation, remove_validation, update_conditional_formats, set_sql_code_cell_value, import_file, undo, redo, or batch | |
| params | No | Parameters for the action (see tool description). For batch: {actions: [{action, params}, ...]} |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds extensive behavioral details: calling convention, special actions (batch, context), warnings (e.g., 'Don't place over existing data unless requested'), and per-action constraints (e.g., code cell output size).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long but well-organized into sections (Cell Data, Code, etc.) and front-loaded with the calling convention. However, it is more verbose than necessary, containing redundant details for similar actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (30+ actions, no output schema), the description is exceptionally complete. It covers all actions, edge cases (e.g., merged cells, batch behavior), and provides examples, ensuring an agent can correctly select and invoke any action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but parameters are generic (action enum, params object). The description compensates fully by detailing every action's parameters, usage, and constraints in the Action Reference, far exceeding schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write operations on the open spreadsheet', specifying the resource (spreadsheet) and verb (write). It distinguishes from sibling tools like read_data (read) and files_write (file operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by listing actions and their specific use cases (e.g., 'For complex tasks use set_code_cell_value'). However, it lacks explicit when-not-to-use or alternatives like 'Use read_data for reading'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!