Grist MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.38
Disambiguation5/5
Each tool targets a distinct operation: document CRUD, record retrieval via filters or SQL, workspace listing, schema and page management, webhooks, and help. The only potential overlap is between grist_get_records and grist_query_sql, but their descriptions clearly differentiate simple filtering from complex SQL joins.
Naming Consistency5/5
All tools consistently follow the 'grist_verb_noun' pattern (e.g., grist_create_document, grist_manage_records, grist_query_sql). The naming is uniform and predictable across the set, with no mixed conventions like camelCase or random verbs.
Tool Count5/5
With 11 tools, the server is well-scoped for a Grist integration. It covers essential operations for documents, records, schema, pages, webhooks, and queries without excessive granularity or unnecessary overlap.
Completeness4/5
The tool surface covers most lifecycle operations: creating and reading documents, full CRUD for records, schema modifications, page layout, and webhook management. Notably missing are update and delete for documents, and workspace modification, but these are minor gaps for typical workflows.
Average 3.3/5 across 11 of 11 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on December 23, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds some behavioral info beyond annotations (e.g., create_page returns sectionIds, use link_widgets to connect). Annotations already indicate destructive hint, but description does not elaborate on destructive behavior. Some added value but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point but incomplete and cut off. It could be more structured and informative while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 3 parameters, 2 required, no output schema. Description is truncated and does not cover return values or full usage context. Refers to grist_help for full schema, indicating incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description must compensate heavily. It mentions operations like create_page, set_layout, link_wi, but does not describe docId or response_format. Partial meaning for operations only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'Declarative page layouts' and lists actions like create_page, but it is incomplete and does not clearly differentiate from sibling tools. The purpose is somewhat clear but not fully articulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description hints at using grist_help for full schema but does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description adds little behavioral context. It mentions 'batch' but does not detail the scope of changes, potential side effects (e.g., data loss on column deletion), or any permissions/auth requirements. The description is truncated and misses opportunity to elaborate on safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads purpose, but it is truncated (ends with 'aut') and relies on external help (grist_help) for completeness, which undermines self-containment. Every sentence earns its place but the incomplete final sentence reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of batch schema operations and the lack of output schema or parameter descriptions, the description is insufficiently complete. The requirement to use grist_help for full schema highlights a gap. Important details like the structure of the 'operations' array, error handling, or transaction behavior are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the description does not explain any parameters (docId, operations, response_format). The only parameter-related hint ('Ref columns need refTable') is vague and not linked to the schema. The description fails to add any meaning beyond the raw schema, leaving the agent to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool handles batch schema operations on tables, columns, and summary tables, with specific verbs like create/rename/delete and add/modify/remove. This distinguishes it from sibling tools focused on documents, records, or pages, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for schema modification and provides a constraint ('Ref columns need refTable'), but does not explicitly state when to use this tool versus alternatives or exclude certain contexts. The suggestion to use grist_help for full schema hints at complexity but doesn't guide the agent on conditional usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, idempotent, non-destructive operation. The description adds context about detail levels and search methods, but does not disclose pagination behavior (offset/limit) or response format, which are present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but incomplete; the detail levels sentence is truncated. It includes an example and a referral to another tool, which saves space but undermines self-containment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and incomplete description, the context is insufficient for reliable tool invocation. The referral to grist_help is a crutch; the description should stand alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions docId, name_contains, workspaceId, and detail_level implicitly, but fails to explain offset, limit, response_format. It defers to grist_help for full schema, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding documents by various methods (ID, name, workspace, browse all). It distinguishes from sibling tools like grist_get_records (records vs documents) and grist_get_workspaces. However, the description is truncated, missing the full detail level options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use each search method (e.g., 'by ID (fastest)'), but does not explicitly contrast with sibling tools or state when not to use this tool. There is no guidance on prerequisites or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint, covering safety. The description adds detail levels and token estimates, but does not explain behavior for optional parameters (offset, limit) or response format, and truncation limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but clearly truncated (ends mid-word). The inclusion of an example and inline code is helpful, but the incomplete structure and lack of full sentences reduce conciseness and professionalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, no output schema), the description is incomplete: it fails to explain multiple parameters, the return format, or pagination. While annotations are rich, the description does not sufficiently cover the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially describes detail_level with token estimates, but does not explain docId, tableId, response_format, offset, or limit. This is insufficient for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves table structure and schema, and explains detail levels (names, columns, full_schema). However, the description appears truncated (ends with '+ t'), slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides token estimates and suggests using grist_help for full schema, giving some usage guidance. It does not explicitly differentiate from sibling tools like grist_manage_schema or grist_get_records, leaving the agent to infer when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint=true). The description adds that operations are sequential, but lacks details on what gets destroyed or auth requirements. Marginal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but cut off mid-sentence, making it incomplete. Front-loading is good, but the truncation harms clarity and professionalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (CRUD with batched operations), the description is insufficient. It lacks return value info, error handling, and limitations. The cut-off sentence leaves ambiguity about formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides an example but does not explain each parameter's meaning or format. The cut-off sentence ('no L prefix') is incomplete, and 'response_format' is undocumented.
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 clearly states the tool performs CRUD operations on records (add, update, delete, upsert). It distinguishes from sibling tools like grist_get_records (read-only) and grist_manage_schema (schema management).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'batched operations execute sequentially for cross-table dependencies' but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The example helps but guidelines are implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that the tool supports batch CRUD and that certain operations are solo, providing some context beyond annotations. However, it does not fully disclose behavior like what happens on failure or the effects of clear_queue.
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 concise with two sentences plus an example and a reference. It is front-loaded with the core purpose. No redundant information, though the example could be more tightly integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of output schema, the description provides a basic understanding but omits details about optional parameter 'response_format', error handling, and return values. The reference to grist_help for full schema is helpful but does not fully compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an example detailing the structure of the 'operations' array, including fields like url, tableId, and eventTypes. This partially compensates for the lack of parameter descriptions. However, 'response_format' is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for batch webhook CRUD for real-time notifications, specifying the verb 'manage' and resource 'webhooks'. It also mentions that certain operations must be solo, adding specificity, but does not explicitly differentiate from sibling tools like grist_manage_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a constraint that list and clear_queue must be solo operations, but lacks guidance on when to use this tool versus alternatives such as grist_query_sql or grist_manage_records. No explicit when-to-use or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe read operation. The description adds filter syntax behavior and notes 'No SQL needed', but does not disclose potential large result sets or rate limits. It does not contradict annotations.
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 short and front-loaded with the main action, followed by an alternative tool mention, filter syntax, and an example. One redundant instruction to use grist_help could be omitted, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain return values. Pagination (offset/limit) and column selection are not described. The agent would lack guidance on handling large results or customizing output, making the description incomplete for full autonomy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). The description only explains the 'filters' parameter via example, leaving offset, limit, columns, and response_format unexplained. Most parameters require additional context not provided.
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 clearly states the tool fetches records with filters and explicitly distinguishes it from grist_query_sql for JOINs/aggregations. The verb 'Fetch' and resource 'records' are specific, and the sibling differentiation is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use grist_query_sql for JOINs/aggregations, and gives an example filter syntax. However, lacks advice on pagination, column selection, or prerequisites like workspace/document IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds behavioral detail: the two modes of operation (param absence vs presence). However, it does not explain other behavioral traits like pagination or error handling, so limited added value beyond annotations.
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 short (three sentences plus example), with purpose and usage front-loaded. However, the example is empty braces (missing param example), and the structure could be improved by listing param roles. Still, no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with 0% schema coverage and no output schema, the description is incomplete. It only addresses the 'tools' param, leaving significant gaps. The agent cannot properly invoke the tool for tasks like filtering by tool_name or topic without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains one parameter ('tools') out of five. Parameters 'only', 'tool_name', 'topic', and 'response_format' are untouched. The description adds minimal meaning beyond the schema, leaving the agent uninformed about critical filtering options.
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 clearly states the tool's purpose: 'Discover available tools and get detailed documentation with JSON schemas.' It distinguishes itself from sibling tools (all data operations) by being a meta-help tool. The verb 'discover' and 'get' with resource 'tool documentation' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage guidance: 'Call without params to list all tools. Use tools param for full docs + schemas.' Includes an example. Does not explicitly state when not to use, but the purpose is clearly differentiated from siblings, so usage context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint; the description adds context about detail levels and modes, but does not discuss rate limits, auth, or pagination beyond limit.
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 concise with three sentences and an example, front-loading purpose and modes; the reference to grist_help is useful but adds minor overhead.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 5 optional parameters and no output schema, the description should cover pagination and all filtering options; it partially covers limit and name_contains but omits offset and response_format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage; the description adds meaning for limit and name_contains via example, and mentions detail_level, but does not cover offset, response_format, or detail_level options fully.
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 clearly states the tool lists workspaces with filtering, using verbs like 'List' and specifying browse vs search modes, distinguishing it from sibling tools like grist_get_documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use browse mode (limit: 20) vs search mode (name_contains), and references grist_help for full schema, but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world semantics. The description adds context about supported query types (JOINs, aggregations, complex filters) and parameterization, which complements the annotations without contradiction. No additional behavioral details are needed given the annotation coverage.
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 concise, consisting of two clear sentences plus a relevant example. Information is front-loaded and directly addresses the tool's core functionality. The example adds value but is somewhat verbose; still, it maintains overall readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (SQL queries, 6 parameters, no output schema), the description is incomplete. It omits details about response_format, offset, limit, and how parameters work. The reference to external help via grist_help is a gap; the description should stand alone. It covers the essential distinction from siblings but fails to fully inform usage of optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with 0% description coverage. The description only implicitly mentions docId and sql via the example, and hints at parameterized queries for the 'parameters' array. It provides no explanation for response_format, offset, or limit, leaving significant ambiguity. The description does not compensate adequately for the lack of schema descriptions.
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 clearly states the tool executes SQL queries for JOINs, aggregations, and complex filters. It explicitly distinguishes from the sibling tool grist_get_records by stating its use for single-table queries without SQL, leaving no ambiguity about when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs grist_get_records for single-table queries. It also mentions support for parameterized queries and references grist_help for full schema, though it does not specify any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, non-idempotent, and open-world. The description adds that it returns ID and URL and optionally forks, but lacks details on permissions, side effects, or duplicate handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences and an example. Every sentence adds value, and the key information is front-loaded.
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?
Given the absence of an output schema, the description explains return values. It covers the main purpose and a key option (fork), but does not address error handling or all parameters in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides an example showing required parameters (name, workspaceId) and mentions forking, partially covering forkFromDocId. However, response_format is not explained, and forkFromDocId format is vague.
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 clearly states it creates a new Grist document, optionally forks an existing one, and returns the new document ID and URL. This distinguishes it from siblings like grist_get_documents (read-only) and other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's function but does not explicitly state when to use it versus alternatives. However, the name and context imply it's the correct tool for document creation, and the fork option adds clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![grist-mcp-server MCP server](https://glama.ai/mcp/servers/gwhthompson/grist-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/gwhthompson/grist-mcp-server)

Score Badge

Copy to your README.md:

[![grist-mcp-server MCP server](https://glama.ai/mcp/servers/gwhthompson/grist-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/gwhthompson/grist-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/gwhthompson/grist-mcp-server'

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