Grist MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes with detailed descriptions. Some overlap exists, such as between add_grist_records and its safe variant, and between multiple query tools (list_records, filter_sql_query, execute_sql_query), but the descriptions clearly differentiate them. The high number of tools increases potential confusion, but overall an agent can distinguish them.
Naming Consistency3/5
Tools follow a verb_noun pattern, but there is inconsistency in verb choice (e.g., create_ vs modify_ vs update_, list vs describe, download vs export). Some names include redundant prefixes like 'grist' or 'document'. While readable, the pattern is not perfectly uniform.
Tool Count3/5
54 tools is a large number, covering many aspects of Grist document management. While the count is justified by the API surface, it includes some redundancy (e.g., add_grist_records and add_grist_records_safe). The set could be streamlined, but it is not excessive for a comprehensive data management server.
Completeness5/5
The tool set covers a very wide range of operations: CRUD for organizations, workspaces, documents, tables, columns, records; advanced querying; attachments; webhooks; access control; schema management; exports; and administrative tasks. There are no obvious gaps for the intended domain of Grist document management.
Average 4.2/5 across 50 of 54 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on September 4, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the return format (dict with status, message, list of attachments) and does not disclose read-only nature, error handling, pagination, or side effects. Minimal behavioral insight.
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 relatively concise, with a clear structure using headings for prérequis, args, and returns. It is front-loaded with the purpose and avoids unnecessary words.
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 no annotations, the description should be more comprehensive. It misses behavioral traits like idempotency, authentication requirements, and what happens with invalid doc_id. The output schema is assumed but not detailed enough to ensure complete understanding for an AI agent.
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 the description must compensate. It adds meaning for sort (column de tri) and limit (nombre maximum de résultats), and links doc_id to list_documents prerequisite. However, it lacks detail on valid sort values, default behavior, or constraints, leaving 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 it lists attachments of a Grist document, using specific verb 'Liste' and resource 'pièces jointes'. It is distinct from sibling tools like download_attachment or get_attachment_info, but does not explicitly differentiate itself from other list 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 provides a prerequisite (list_documents to obtain doc_id) and notes optional parameters for sorting and limiting. It gives clear context for when to use, but does not mention exclusions or alternatives.
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?
No annotations are provided, so the description fully carries the burden of behavioral disclosure. It mentions clearing the queue but does not detail side effects, such as whether this action is destructive, requires specific permissions, or affects other aspects of the document or webhooks. The return type is briefly mentioned but no behavioral constraints.
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 a brief purpose statement, a usage scenario, and a structured Args/Returns section. No extraneous information is present, and the key information is front-loaded. However, it could be more structured with a clearer separation of guidelines.
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 lack of annotations and the single parameter, the description is minimally complete. It explains the purpose and outcome (returns a Dict with status and message), but omits crucial context about system state changes, prerequisites, error scenarios, and the irreversible nature of clearing a queue. For a destructive action, more completeness is expected.
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?
Schema description coverage is 0%, yet the description only rephrases the parameter name with 'doc_id: L'ID du document'. It adds no additional meaning, constraints, format, or examples beyond what the schema provides (string, required). This is insufficient for a tool with undocumented parameters.
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 action 'Vide la file d'attente des webhooks' (clears the webhook queue) and the target resource 'pour un document' (for a document). This verb+resource combination is specific and distinguishes it from sibling tools like create_webhook, delete_webhook, list_webhooks, and modify_webhook.
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 a clear use case: 'Utile en cas d'accumulation de notifications non envoyées' (useful in case of accumulation of unsent notifications). It suggests when to use the tool, though it does not explicitly state when not to use it or mention alternative tools for other scenarios.
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?
No annotations are provided, so the description carries full burden. It states the operation but does not disclose important behavioral traits such as conflict handling (e.g., if new_table_id already exists), side effects on data, or authorization requirements.
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 structured with clear sections for prerequisites, arguments, and returns. It avoids unnecessary details, though it could be slightly more condensed.
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?
The tool modifies a table with simple parameters and an output schema exists. The description provides a high-level overview but lacks details on potential errors, idempotency, or what happens on success/failure.
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 schema has 0% description coverage, so the description must compensate. It briefly explains the three parameters (doc_id, table_id, new_table_id) but lacks detail on formats, constraints, or specific requirements, providing only basic 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 it modifies table properties, using a specific verb and resource. However, it does not differentiate from sibling tools like modify_column, and does not specify which properties beyond renaming.
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 lists a prerequisite (use list_tables to get a valid table_id) which is helpful. It does not explicitly mention when not to use the tool or provide alternatives, so usage context is implied rather than explicit.
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?
Without annotations, the description should disclose behavioral traits. It states it adds records and returns IDs, but does not mention side effects (e.g., idempotency, error behavior, or whether it overwrites existing data). The return structure is described, but deeper behavioral context is missing.
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 well-structured with Args and Returns sections and an example, but is slightly verbose. It could be more concise while retaining all necessary information.
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 tool has 3 required parameters and an output schema (described in text), the description covers input and output adequately. However, it lacks information on error handling, validation, or limitations, leaving some gaps for an agent.
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?
The input schema has 0% description coverage (no parameter descriptions in JSON), but the tool description adds detailed meaning for each parameter, including an example for 'records' that clarifies the expected structure. This adds significant value beyond the schema.
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 adds records to a Grist table, using a specific verb and resource. However, it does not differentiate from the sibling tool 'add_grist_records_safe', which shares a similar purpose.
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 guidance is provided on when to use this tool versus alternatives like 'add_grist_records_safe' or other modification tools. The description lacks context on prerequisites or conditions for use.
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?
No annotations are provided, so the description carries full burden. It only states 'modifies' (mutation) and lists parameters. Lacks details on authorization, side effects, reversibility, or rate limits.
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?
Well-structured with clear sections (Prerequisites, Args, Returns) and brief parameter descriptions. No wasted words; each sentence adds value.
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?
Covers purpose, prerequisites, all parameters, and return type. However, lacks examples, constraints, or error handling details. Output schema exists but description provides only vague return format.
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 0%, so description must compensate. It lists all 11 parameters with brief explanations (e.g., 'formula: empty string to remove'). Adds meaning beyond the schema, though not deeply specifying valid values.
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 states 'modify column properties' clearly with a specific verb and resource. It distinguishes from siblings like create_column or delete_column implicitly, but does not explicitly differentiate.
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?
Provides a prerequisite (list_columns to get column_id) which is helpful. However, no guidance on when not to use this tool or comparison with alternatives like update_grist_records.
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?
No annotations are provided, so the description carries the full burden. It outlines the algorithm steps, including optional data insertion and handling of existing tables via skip_existing. However, it does not disclose permissions, potential side effects (e.g., whether it overwrites existing schema), or error conditions, which limits its transparency.
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 well-structured with a title line, an algorithm numbered list, and labeled argument definitions. It conveys substantial information without excessive verbosity, though the algorithm details could be slightly more concise.
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?
The description covers the creation process, parameters, and return value (a dict with a detailed report). It lacks details on prerequisites, error handling, or output schema specifics, but given the tool's complexity and the presence of an output schema (not shown), it provides a solid foundation.
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 description coverage is 0%, but the description adds clear explanations for all four parameters (doc_id, schema, skip_existing, insert_data), including defaults. This adds meaning beyond the bare schema types and names.
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 'Crée un schéma complet avec tables, colonnes et relations' (creates a complete schema with tables, columns, and relations), using a specific verb and resource. It distinguishes from sibling tools like create_table or create_column by indicating it handles the entire schema in one operation.
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 no explicit guidance on when to use this tool versus alternatives like create_table or create_column. There is no mention of scenarios where incremental creation is preferred or when to use this tool over the others.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It explicitly states the action is irreversible and deletes all documents and data associated with the workspace, and mentions the return type (Dict with status and message). This provides good transparency for a destructive operation.
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 and well-structured with a clear main sentence followed by a warning in a separate paragraph. It contains no unnecessary words and is front-loaded with the key action. However, it could be slightly more comprehensive without becoming verbose.
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?
The description is adequate given the tool has one parameter and an output schema (which covers return values). However, it lacks guidance on prerequisites (e.g., required permissions, whether the workspace must be empty) and does not help differentiate from other delete tools like delete_document or delete_organization, which could lead to incorrect tool selection.
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 description explains workspace_id as 'L'ID de l'espace de travail à supprimer' (the ID of the workspace to delete), which adds minimal semantic value beyond the input schema (which already defines it as a required integer). With 0% schema description coverage, more detail could have been provided, such as how to obtain the ID or any constraints (e.g., cannot delete the default workspace).
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 'Supprime un espace de travail' (Delete a workspace), which is a specific verb-resource pair. It effectively distinguishes from sibling tools like create_workspace, modify_workspace, and describe_workspace.
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 includes an explicit warning about irreversibility and deletion of all associated data, which informs when to use it (only when full deletion is intended). However, it does not provide explicit guidance on when not to use it or suggest alternative tools for related tasks like archiving or disabling a workspace.
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?
With no annotations, the description must disclose behavior. It mentions the export action and the optional include_data parameter's 100-record limit. However, it does not confirm whether the operation is read-only or requires specific permissions, leaving some behavioral gaps.
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 extremely concise, using a clear header and bullet-like args/returns. Every sentence adds value, with no redundancy or filler.
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?
The description covers inputs and return value but omits prerequisites (e.g., document existence) and error conditions. Given the simplicity and presence of output schema, it is adequate but not fully complete.
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?
Despite 0% schema coverage, the description explains all three parameters: doc_id, format (listing values json, yaml, mermaid), and include_data (limiting to 100 records). This adds meaning beyond the schema's bare types and defaults.
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 exports the schema of an existing document, using a specific verb and resource. It distinguishes from sibling tools like 'create_schema' or 'get_table_schema' by focusing on export in various formats.
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 no guidance on when to use this tool versus alternatives, nor any exclusions or context. It simply states what it does, leaving the agent to infer usage.
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?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic modification action. It lacks details on idempotency, permissions, side effects, or reversibility, which are important for a mutate tool.
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 and well-structured with clear sections for Prerequisites, Args, and Returns. Every sentence serves a purpose without unnecessary detail.
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 presence of an output schema (indicated by context signals), the description appropriately notes the return type (Dict with status and message). For a simple two-parameter tool, it covers the essential information, though missing error handling details.
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?
The schema has 0% description coverage, so the description must compensate. It provides meaningful explanations for workspace_id (ID of workspace to modify) and name (optional new name), adding context beyond the schema types.
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 it modifies workspace properties, distinguishing it from create/delete/list siblings. However, it says 'properties' but only lists one property (name) in the args, causing slight ambiguity.
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 explicitly lists a prerequisite (list_workspaces to get workspace_id), which guides when to use. However, it does not mention when not to use or alternatives like modify_workspace_access.
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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It explains parameters and the return format (dict with base64-encoded content), implying a read-only download with no destructive side effects. However, it omits details like potential errors, size limits, or authentication requirements, leaving some behavioral aspects unclear.
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 well-structured with sections for prerequisites, args, and returns. It conveys necessary information concisely without extraneous text. Minor improvement could be removing 'Args:' and 'Returns:' labels since the structure is already clear, but it remains efficient.
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 that an output schema exists (context signal), the description covers the return format (dict with status, message, base64 content). It also includes prerequisites and parameter explanations. For a straightforward download tool, this is mostly complete, though details on error cases or performance characteristics are missing.
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?
The input schema has 0% parameter descriptions, so the description must compensate. It does so by explaining each parameter: doc_id (document ID), nohistory (excludes history), template (downloads as template without user data). This adds meaning beyond the schema's type and default values, making the tool usable.
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 downloads a Grist document in SQLite format. It uses a specific verb ('Télécharge'), resource ('document Grist'), and output format ('SQLite'). This distinguishes it from siblings like download_document_excel and download_table_csv, which target other formats.
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 lists a prerequisite (list_documents to get a valid doc_id), which provides usage context. However, it does not explicitly guide when to choose this tool over alternatives like download_document_excel or download_table_csv, nor does it state when not to use it. More explicit differentiation would improve this dimension.
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?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication needs, or side effects. It only mentions the return format.
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 clear sections for prerequisites, args, and returns. It is well-structured and front-loaded, but could be slightly more compact.
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 simple one-parameter tool and presence of an output schema, the description covers prerequisites, parameter, and return value adequately. Lacks details on pagination or filtering but sufficient for basic usage.
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?
The description explains the org_id parameter as 'L'ID de l'organisation' and mentions a prerequisite to obtain a valid ID, adding meaning beyond the schema which only specifies type. Schema coverage is 0%, so description compensates well.
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 that the tool lists users with access to an organization. It is specific and distinct from sibling tools like list_workspace_access and list_document_access.
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 a prerequisite (use list_organizations to get org_id), guiding when to use the tool. However, it does not explicitly mention when not to use it or alternatives.
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?
No annotations provided. Description does not disclose side effects, authorization needs, or whether updates are partial or full. Lacks behavioral detail beyond basic mutation.
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?
Well-structured with sections (Prérequis, Args, Returns). Each sentence is concise and relevant. No extraneous text.
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?
Returns are briefly described as 'Dict avec statut et message'. With an output schema present, this is adequate but lacks error handling or edge-case details. Moderate completeness.
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 0%, so description compensates by explaining each parameter's purpose (e.g., 'Nouvelle URL du webhook (optionnel)'). All 7 parameters are documented with clear meaning.
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?
Clearly states 'Modifie un webhook existant' (modify an existing webhook). Verb+resource is explicit, and it distinguishes from siblings like create_webhook, delete_webhook.
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?
Lists prerequisite: use list_webhooks to get a valid webhook_id. Provides clear context for when to use this tool, but does not explicitly state when not to use or mention alternatives.
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?
No annotations are provided, so the description carries the full burden. It discloses the return format (Dict with status, message, base64 content) but does not mention side effects, auth needs, or error conditions. This is adequate but not thorough.
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 well-structured with clear sections: title, prerequisites, args, returns. Every sentence adds value without redundancy or fluff.
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?
For a simple download tool with output schema present, the description covers prerequisites and return format. It is nearly complete, though missing potential error handling details.
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 adds meaning by explaining each parameter (doc_id is document ID, attachment_id is attachment ID). However, it lacks details on format, constraints, or examples, providing only minimal clarification.
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 verb 'download' and the resource 'attachment content'. It distinguishes from sibling tools like get_attachment_info (metadata) and upload_attachment by explicitly mentioning prerequisites that involve them.
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?
Prerequisites are listed (list_attachments, get_attachment_info) providing clear context for when to use this tool. However, it does not explicitly state when not to use it or provide alternatives beyond the 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?
No annotations are provided, so the description must bear the full burden. It states the return type (dict with status, message, webhook list), but does not explicitly confirm it is read-only or mention rate limits, auth needs, or side effects. The name implies listing, but more specificity would improve transparency.
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 a clear main purpose, prerequisites, and structured args/returns. Every sentence is necessary and 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?
For a simple list operation with one parameter and no annotations, the description covers the purpose, prerequisite, parameter, and return format adequately. It could mention the read-only nature explicitly, but overall it is complete.
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?
The input schema has only doc_id without description, but the tool description adds that it is the document ID and mentions the prerequisite list_documents to obtain it. This adds meaningful context beyond the bare schema.
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 webhooks for a Grist document. It distinguishes itself from sibling tools like create_webhook and delete_webhook by focusing on listing.
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 a prerequisite (list_documents to get doc_id), indicating when to use this tool. However, it does not explicitly discuss when not to use it or compare to alternatives like clear_webhook_queue.
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?
With no annotations provided, the description alone must disclose behavior. It indicates the return type (dict with status, message, details), but omits details about side effects (likely read-only), error handling for invalid workspace_id, or authentication requirements. The information is partially transparent but lacks depth.
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 concise and well-structured: a one-line purpose, followed by prerequisites, arguments, and returns in a clear bulleted format. Every sentence serves a function, and the information is front-loaded with the core action.
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 tool's simplicity (single required integer parameter) and the presence of an output schema, the description covers the essential aspects: what the tool does, how to prepare, and what to expect in the response. It lacks explicit differentiation from similarly named siblings but is otherwise complete.
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 provides only a type (integer) for workspace_id with 0% description coverage. The description adds the meaning 'L'ID de l'espace de travail', which clarifies the parameter's purpose. This compensates for the schema's lack of description but does not go beyond a basic label.
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 explicitly states the action 'liste les utilisateurs ayant accès' (list users with access) and identifies the resource 'un espace de travail' (a workspace). This clear verb+resource combination distinguishes the tool from sibling tools such as 'list_workspaces' (which lists workspaces) and 'list_document_access' (which deals with 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 lists a prerequisite ('list_workspaces') to obtain a valid workspace_id, providing clear context for when the tool should be used. However, it does not explicitly state when not to use it or mention alternative tools like 'list_organization_access', though the uniqueness of workspace access is implied.
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?
No annotations are provided, so the description must disclose behavioral traits. It only states that it modifies properties and returns a dict with status and message, but does not mention side effects, required permissions, or reversibility of the modification.
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 concise and well-structured, with a main sentence, a prerequisite section, and explicitly labeled Args and Returns. It is front-loaded with the core action and avoids redundancy.
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?
The description covers the inputs and output adequately, and includes a prerequisite step. However, given the absence of annotations and the fact that this is a modification tool, it could benefit from mentioning that changes are applied immediately or require specific permissions.
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 0%, so the description must explain parameters. It does so by defining org_id as the ID of the organization to modify and name as an optional new name, which adds meaning beyond the schema's type definitions.
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 'Modifie les propriétés d'une organisation', which is a specific verb-resource combination. It distinguishes from sibling tools like delete_organization, describe_organization, and list_organizations.
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 includes a prerequisite to use list_organizations to obtain a valid org_id, providing context for when to use this tool. However, it does not explicitly state when not to use it or mention alternative tools for modifying organization access.
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?
No annotations are provided, so the description carries full burden. It explains the tool creates a webhook and returns status and ID, but does not disclose potential side effects, idempotency, or error scenarios. Adequate but not thorough.
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 reasonably concise with clear sections (prerequisites, args, returns). However, it includes some redundancy (e.g., doc_id and table_id are already explained in prerequisites) and could be slightly more streamlined.
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 tool's complexity and the presence of an output schema, the description covers prerequisites, parameters, and return values. It misses guidance on error handling or rate limits, but for a creation tool this is sufficient.
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 description coverage is 0%, so the description must compensate. It explains all parameters: doc_id, url, table_id, event_types (with possible values), and memo, adding meaning beyond the schema. URL format could be clarified, but overall good.
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 creates a webhook for a Grist document, using a specific verb and resource. It distinguishes itself from sibling tools like delete_webhook, modify_webhook, and list_webhooks.
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 prerequisites (list_documents and list_tables) and explains optional parameters. However, it does not explicitly state when not to use this tool or suggest alternatives like modify_webhook for existing webhooks.
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?
No annotations provided, so description carries full burden. It indicates deletion but does not discuss idempotency, error handling for non-existent webhooks, or any side effects beyond the operation.
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 well-structured with headings (Prérequis, Args, Returns) and is concise. Every sentence adds value, though the blank line before Args could be omitted.
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 simplicity of the tool (2 params, no nested objects), the description covers prerequisites, parameters, and return type. With an output schema and sibling tools, it is sufficiently complete, though it could explicitly differentiate from clear_webhook_queue.
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?
With 0% schema description coverage, the description adds meaning by explaining each parameter: doc_id as document ID and webhook_id as the ID of the webhook to delete. This compensates for the schema's lack of 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 explicitly states 'Supprime un webhook' (delete a webhook), which is a specific verb and resource. It clearly distinguishes from sibling tools like create_webhook, modify_webhook, clear_webhook_queue.
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 a clear prerequisite calling list_webhooks to obtain a valid webhook_id, guiding usage. Does not explicitly state when not to use, but the context of deletion is straightforward.
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?
No annotations are provided, so the description must fully disclose behavioral traits. While it mentions 'force reload', it does not specify potential side effects (e.g., loss of unsaved changes), authentication requirements, or rate limits. The behavior beyond the action is not transparent.
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 concise and front-loaded: a one-line purpose, a one-line use case, then structured Args and Returns. Every sentence adds value with no unnecessary information.
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?
For a simple tool with one parameter and an output schema, the description covers purpose, usage, parameter semantics, and return structure. It is slightly lacking in behavioral detail (e.g., destructive nature of 'force reload'), but overall complete enough for an agent to use it correctly.
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 description coverage is 0%, but the description includes an Args section that defines the single parameter 'doc_id' as 'L\'ID du document à recharger' (the ID of the document to reload). This fully compensates for the missing 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 states 'Force le rechargement d'un document' (force reload of a document) and specifies it is useful for inconsistencies or sync problems. This is a specific verb+resource, clearly distinguishing it from siblings like create_document, delete_document, and modify_document.
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 a clear use case: 'Utile en cas d'incohérences ou de problèmes de synchronisation' (useful in case of inconsistencies or sync problems). However, it does not explicitly state when not to use the tool or list alternatives, though the context is clear enough for an agent.
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?
With no annotations provided, the description carries the full burden. It discloses the return structure (success, message, workspace) but does not explicitly state that the operation is read-only or discuss permissions, rate limits, or error cases.
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 well-structured with Prerequisites, typical workflow, Args, and Returns sections. It is not overly verbose, though the workflow could be condensed.
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's simplicity (one parameter) and the existence of an output schema, the description adequately covers prerequisites, workflow, and return values. It provides sufficient context for an agent to use the tool correctly.
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?
The input schema has no description for workspace_id (0% coverage). The description compensates by explaining 'L'ID de l'espace de travail à décrire', adding meaning beyond the type integer.
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 gets detailed information about a specific workspace. It uses a specific verb-resource pair and distinguishes itself from sibling tools like list_workspaces and describe_document.
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 prerequisites (workspace_id from list_workspaces) and a typical workflow (list_organizations -> list_workspaces -> describe_workspace). However, it does not mention when not to use this tool or describe alternative tools for similar tasks.
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?
With no annotations provided, the description carries the full burden. It states the return type (dict with status, message, metadata) but lacks details on side effects, rate limits, or authentication requirements, which is adequate but not rich.
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 well-structured with clear sections (main sentence, prerequisite, args, returns) and concisely covers all necessary information without wasted words.
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 tool's simplicity (2 required params, no annotations) and presence of an output schema, the description adequately covers prerequisites, arguments, and return type, though it could elaborate on the metadata structure.
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 0%, so the description is essential. It defines both parameters with meaningful French explanations (doc_id: L'ID du document, attachment_id: L'ID de la pièce jointe) and specifies attachment_id is an integer, adding value beyond the empty schema.
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 verb 'obtient' and resource 'métadonnées d'une pièce jointe', distinguishing it from sibling tools like list_attachments and download_attachment.
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 a prerequisite (use list_attachments to get a valid attachment_id) and lists required arguments, offering clear context for usage, though it does not explicitly state when not to use the tool or mention alternatives.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that properties are modified (name, is_pinned) and returns a status/message, but it does not detail potential side effects, permissions, or reversibility. With missing annotations, the description is adequate but not highly transparent.
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 well-structured: a one-line main purpose, a prerequisite section, an args list, and returns. It is concise with no wasted words, and the key action 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 tool has three parameters, one required, and an output schema, the description covers the prerequisite, parameters, and return value. It is largely complete, though it lacks details on error handling or specific constraints, which could be inferred from the output schema.
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 description coverage is 0%, but the description compensates by listing each parameter (doc_id, name, is_pinned) with clear explanations. This adds meaning beyond the raw schema, which only provides types and defaults.
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 'Modifies the properties of a document,' which is a specific verb and resource. It distinguishes itself from sibling tools like delete_document, create_document, and move_document by focusing on property modification.
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 a prerequisite: use list_documents to obtain a valid doc_id. This guides the agent on when to use this tool (after listing documents). However, it does not explicitly mention when not to use it or alternatives, leaving room for improvement.
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?
Aucune annotation n'est fournie, donc la description doit tout divulguer. Elle décrit les vérifications effectuées et indique qu'il n'y a pas de création, mais ne mentionne pas les permissions requises, les limites de taux ou le format exact des erreurs. Le comportement est partiellement transparent.
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?
La description est concise, commence par l'objectif principal, utilise des puces pour les vérifications, et sépare clairement les arguments et les retours. Aucune information superflue.
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?
Le schéma de sortie existe (contextuel), donc la description n'a pas besoin de détailler le format de retour ; elle mentionne 'statut, erreurs et warnings', ce qui est suffisant. La couverture est bonne pour un outil simple à deux paramètres.
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?
Bien que la couverture de description du schéma soit de 0%, la description ajoute des explications pour chaque paramètre : doc_id pour vérifier les tables existantes, schema pour le format dict. Cela compense largement le manque de documentation dans le schéma.
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?
La description spécifie clairement le verbe 'valider' et la ressource 'schéma', et se distingue de l'outil frère 'create_schema' en indiquant qu'il s'agit d'une validation sans création. La liste des vérifications renforce la clarté.
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?
La mention 'sans le créer' implique une utilisation avant la création, mais il manque une indication explicite sur quand ne pas l'utiliser ou des alternatives précises. Cependant, le contexte des outils frères (create_schema) est implicite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently discloses that the tool validates table and column existence before inserting and suggests corrections. It also outlines the return dict structure (status, message, suggestions, created IDs). This is thorough for a mutation 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?
The description is well-structured with sections for prerequisites and workflow, but it is slightly verbose. Each sentence adds value, though some repetition exists (e.g., repeating parameter names in Args after being mentioned earlier). Overall, it's clear and digestible.
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 that an output schema exists, the description need not detail return values, but it does so anyway. It covers purpose, prerequisites, workflow, and error handling (corrections). The addition of a suggested workflow makes it complete for a moderately complex tool.
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 description's 'Args' section merely lists parameter names without adding meaning beyond the input schema. Schema coverage is 0%, so the description should compensate, but it provides no details on parameter formats, constraints, or examples. This is a significant gap.
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 main action (adding records) and its distinguishing feature: prior structure validation. It specifies the verb 'Ajoute' and the resource 'enregistrements', and differentiates from the sibling 'add_grist_records' by the 'safe' validation behavior.
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 a typical workflow (get_table_schema, then this tool, then list_records) and notes that internal calls to list_tables and list_columns are automated. However, it does not explicitly state when not to use this tool or contrast it with alternatives like 'add_grist_records'. It implies usage but lacks exclusions.
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?
No annotations are provided, so the description bears the full burden. It transparently describes the four-step process: checking table existence, resolving column name, creating the column, and optionally creating the reverse relation. It also notes the effect of is_list on the column type (Ref vs RefList). This is detailed and honest.
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 well-structured with numbered steps and a parameter list. It front-loads the purpose and provides detailed explanations. While it is slightly verbose due to the number of parameters, every sentence adds necessary information given the low schema coverage. It earns a 4.
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's complexity (8 parameters, reference column with auto-resolution, optional reverse relation) and the presence of an output schema, the description covers the process, parameters, and return format ('Dict avec statut, détails et éventuels warnings'). It is comprehensive and leaves no significant gaps.
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 description coverage is 0%, so the description must compensate fully. It provides an 'Args:' section that explains all eight parameters, including the meaning of visible_column (resolved to colRef), the default for is_list (false), and the optional nature of label and reverse_column. This adds substantial value beyond the schema.
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 reference column with automatic resolution of visibleCol. The verb 'Crée' and the resource 'colonne de référence' are specific. It distinguishes from sibling tools like 'create_column' by detailing the reference-specific logic and steps.
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 does not explicitly state when to use this tool versus alternatives like 'create_column' or 'modify_column'. However, the context of creating reference columns with auto-resolution is clear. There is no guidance on when not to use or prerequisites, but the purpose is adequately implied.
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?
No annotations are provided, so the description carries full burden. It discloses the creation action, the uniqueness constraint on table_id, optional columns with examples, and return data. It does not mention error behavior (e.g., duplicate IDs) or side effects, but overall it provides solid behavioral context beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, prerequisites, workflow, args with examples, and returns. The description is front-loaded with the core purpose, and every sentence adds value. It is appropriately sized for the tool's complexity.
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 tool has an output schema (context confirms), the description's return explanation is sufficient. It covers prerequisites, workflow, and parameter details. It lacks error handling or edge cases like invalid doc_id, but for typical use it is complete. The sibling context shows many tools, but this description stands alone well.
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 0%, but the description adds significant meaning: doc_id is the document ID, table_id must be unique, and columns is a list of column definitions with a detailed example. This compensates well for the schema's lack of descriptions, though a bit more detail on each parameter type would be ideal.
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 it creates a new table in a document ('Crée une nouvelle table dans un document'). It distinguishes from siblings like 'create_column' by specifying the resource 'table', but lacks explicit differentiation from other 'create_' tools. The purpose is clear but could be more specific about its unique role.
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?
Excellent guidance: prerequisites (list_documents to get doc_id), a step-by-step typical workflow, and parameter examples. This explicitly tells the agent when and how to use the tool, including verifying creation. No guidance on when not to use, but the workflow is comprehensive.
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?
With no annotations provided, the description fully bears the transparency burden. It clearly states the action is irreversible and deletes associated data. However, it does not mention required permissions or ownership, which would be helpful for a destructive tool.
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 concise: a one-sentence purpose, a clear warning, and structured Args/Returns. No unnecessary words, and the most important information (irreversibility) is front-loaded.
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 single parameter and the tool's simplicity, the description is complete. It covers purpose, irreversibility, parameter semantics, and return format (Dict with status and message). No gaps remain.
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?
The schema has 0% description coverage, but the description explicitly defines 'doc_id' as 'L'ID du document à supprimer', adding critical context beyond the plain schema type. The single parameter is well-explained.
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 deletes a document and explicitly warns that the action is irreversible and removes all associated data. The name 'delete_document' is unambiguous, and the description distinguishes it from sibling tools like 'delete_column' or 'delete_workspace'.
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 via the name and warning, but lacks explicit guidance on when to use this tool versus alternatives such as 'move_document' or 'modify_document'. No when-not or exclusion criteria are provided.
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?
The description mentions the return format (dict with status, message, and access details) but does not explicitly state that it is a read-only operation or disclose any side effects. Without annotations, this is a moderate disclosure, but it lacks details on permissions or limitations.
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 well-structured with sections for summary, prerequisites, args, and returns. It is concise with no unnecessary words, and the information is front-loaded.
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?
For a simple list tool with one parameter and an output schema, the description covers all necessary aspects: purpose, prerequisite, input, and return. It is complete given the low complexity.
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?
The only parameter 'doc_id' has a clear description in the Args section ('L'ID du document'), and the prerequisite guidance explains how to obtain it. This adds value beyond the bare schema, which has no description for the parameter.
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 verb 'list' and the resource 'document access', and it distinguishes itself from siblings like 'modify_document_access' and 'list_workspace_access'. The prerequisite mention of 'list_documents' further clarifies the context.
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 a clear prerequisite (use 'list_documents' to get a valid doc_id), guiding the agent on how to obtain the required input. While it does not explicitly state when not to use it or alternatives, the sibling tools imply the scope (e.g., modify vs list).
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?
No annotations are provided, so the description carries the full burden. It mentions that access_level can be null to remove access, and states the return type, but does not address permissions, idempotency, or error cases, leaving some gaps.
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 structured with clear sections (purpose, prerequisites, args, returns) and is front-loaded. It is not overly verbose, but a slight reduction in line breaks could improve conciseness.
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 no annotations and an existing output schema, the description covers all aspects: purpose, prerequisites, complete parameter descriptions with valid values, and return type. It provides sufficient context for correct invocation.
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?
The input schema has 0% description coverage, so the description must compensate fully. It does so by describing each parameter and enumerating valid values for access_level (owners, editors, viewers, null to remove), adding critical meaning beyond the schema.
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 action ('Modifies a user's access to a document') and distinguishes the tool from siblings like 'modify_document' or 'modify_workspace_access' by specifying the resource (document access) and target (user).
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 explicitly lists prerequisites (list_documents, list_document_access), guiding the agent on when to use this tool after gathering necessary IDs. It does not specify when not to use it, but the context is clear.
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?
No annotations are provided, so the description carries the full burden. It discloses that setting access_level to null removes access, indicating destructive behavior. However, it does not mention required permissions, idempotency, or other side effects.
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 well-structured with clear sections for prerequisites, parameters, and returns. It is concise but contains slightly redundant information, such as listing prerequisites that might be inferred from the tool's context.
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 no annotations and zero schema coverage, the description thoroughly covers the tool's purpose, parameters, and return value. It even describes the output as a dict with status and message, compensating for the lack of structured metadata.
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?
The description adds meaningful explanations for all three parameters beyond the schema, which has no descriptions. It specifies that org_id is the organization ID, user_email is the user's email, and access_level can be 'owners', 'editors', 'viewers', 'members', or null to remove.
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 modifies a user's access to an organization, using a specific verb and resource. The name and description together differentiate it from sibling tools like modify_workspace_access.
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 lists prerequisites (list_organizations and list_organization_access) that provide context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives.
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?
With no annotations, the description carries full burden. It states the action (modify), notes that setting access_level to 'null' removes access, and indicates a return Dict. However, it does not disclose permissions required, reversibility, or error conditions. This is adequate but could be more transparent.
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 concise, with clear structure: a one-sentence summary, followed by prerequisites in a list, then parameters and returns. Every sentence adds value, and there is no redundancy.
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 tool has 3 required parameters and no output schema shown (though description mentions a return Dict), the description covers the essentials: what the tool does, prerequisites, parameter semantics, and return type. It lacks details on error handling or edge cases, but for this tool, it is largely complete.
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 description coverage is 0%, so the description must compensate. It explains each parameter: workspace_id (L'ID de l'espace de travail), user_email (Email de l'utilisateur), access_level (Niveau d'accès with allowed values: owners, editors, viewers, ou null pour supprimer). This adds meaning beyond the schema's type-only definitions.
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 action: 'Modifie l'accès d'un utilisateur à un espace de travail.' The verb 'modify' and resource 'workspace access' are explicit. It distinguishes from sibling tools like modify_workspace (which alters workspace properties) by focusing on access permissions.
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 prerequisites: list_workspaces and list_workspace_access, guiding the agent to first obtain a valid workspace_id and review current access. It does not explicitly mention when not to use the tool, but the context is clear. Alternatives are not stated, but the tool's specific purpose makes them 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?
With no annotations, the description carries full burden. It describes the operation as a move but does not disclose behavioral traits such as whether the original document is removed from the source workspace, permissions required, or potential side effects. The return format is mentioned, providing some transparency.
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 well-structured with a summary, prerequisites, arguments list, and returns. It is concise and front-loaded, with no wasted sentences.
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?
For a simple move operation, the description covers prerequisites, parameters, and return format. However, it lacks details on error conditions, reversibility, or constraints (e.g., workspace must be in the same organization), which could affect successful invocation.
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?
The description explains both parameters clearly: 'doc_id' as the ID of the document to move and 'target_workspace_id' as the ID of the destination workspace. Since the schema has 0% description coverage, this compensates 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 action ('Déplace un document vers un autre espace de travail') with a specific verb and resource, distinguishing it from sibling tools like create_document or delete_document.
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 prerequisites (list_documents and list_workspaces) to obtain valid IDs, guiding the agent on preparation. However, it does not state when not to use this tool or mention alternatives, which would be helpful given the many sibling tools.
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?
No annotations are present, so the description fully carries the burden. It discloses that the action is irreversible and will delete all associated workspaces, documents, and data. This is critical for safe usage, though it omits details like authentication requirements or error 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 extremely concise with a clear structure: action, warning, arguments, returns. Every sentence adds value, and the important caution 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 tool has only one parameter and is destructive, the description covers the necessary behavioral consequences and return type. However, it could be slightly improved by mentioning potential errors or prerequisites.
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?
The description includes an 'Args' section that explains the parameter 'org_id' as 'L'ID de l'organisation à supprimer', adding meaning beyond the schema which only specifies type. This is valuable for an agent to understand what to provide.
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 'Supprime une organisation' (Deletes an organization), with a specific verb and resource. It distinguishes itself from sibling delete tools by focusing on organizations, and the warning about cascading deletion reinforces the specific scope.
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 a clear warning about irreversibility and cascading deletion, which guides the agent to use this tool with caution. It implicitly tells when not to use (if unsure), but does not explicitly mention alternative actions like archiving.
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?
Although no annotations are provided, the description discloses the return format (dict with success, message, organization) and implies a read-only operation through the name and context. However, it does not mention authentication or rate limits, but for a read tool this is acceptable.
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 well-structured with sections for prerequisites, workflow, args, and returns. While slightly verbose, it is organized and front-loads the main purpose.
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's simplicity, the description covers all essential aspects: purpose, prerequisites, typical use, parameter meaning, and return format. It is complete for an agent to correctly select and invoke this tool.
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%, so the description must compensate. The Args section explains org_id as 'L'ID de l'organisation à décrire', which adds minimal meaning beyond its name and does not clarify the anyOf integer/string type.
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 verb 'obtient' and resource 'informations détaillées sur une organisation spécifique', distinguishing it from sibling tools like list_organizations (listing) and delete_organization (deletion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists prerequisite (list_organizations) and provides a typical workflow step, making it clear when and how to use this tool versus alternatives.
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?
No annotations are provided, so the description must fully disclose behavior. It mentions the return format (dict with status, message, content) and the header parameter options, but it does not explicitly state that the tool is read-only or describe any potential side effects, rate limits, or size constraints.
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 concise: a single main sentence followed by structured bullet points for prerequisites and arguments. Every sentence adds value without redundancy, making it easy to scan.
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 that an output schema exists, the description covers the return format (status, message, content) and explains prerequisites and parameter meanings. For a simple download tool, this is complete and provides sufficient context for an agent to use it correctly.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter: doc_id (from list_documents), table_id (from list_tables), and header (with options label, id, none). This adds significant meaning beyond the schema's basic type and default.
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: 'Télécharge une table Grist au format CSV' (Downloads a Grist table in CSV format). It specifies the verb (download), resource (table), and format (CSV), distinguishing it from sibling tools like download_document_excel or download_document_sqlite.
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?
Prerequisites are explicitly listed: list_documents for doc_id and list_tables for table_id. This provides clear guidance on what to do before using the tool. However, it does not explicitly mention when to use this tool over alternative download tools (e.g., for Excel or SQLite), leaving some ambiguity.
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?
No annotations are provided, so the description carries full responsibility. It explicitly states that only SELECT queries are allowed, implying read-only behavior, and advises secure parameter usage. It does not disclose error handling or performance implications, but the restriction to SELECT is a critical behavior disclosed.
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 well-structured with sections for prerequisites, workflow, security, args, and returns. It is slightly verbose but front-loaded with the main purpose. Every sentence adds value, though some wording could be tightened.
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 complexity of SQL execution, no annotations, and low schema coverage, the description covers prerequisites, workflow, security, and all parameters. It misses interaction with other tools (e.g., how results relate to other Grist operations) but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description explains each parameter in the Args section: doc_id (document ID), sql_query (SELECT only), parameters (for placeholders), timeout_ms (default 1000ms). This adds significant meaning beyond the minimal schema, providing type, default, and usage context.
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 specifies the tool executes custom SQL queries on Grist documents, explicitly limits to SELECT statements, and distinguishes from siblings like filter_sql_query by its support for complex queries with joins and aggregations. The verb+resource+scope is precise 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?
The description provides prerequisites (list_tables, list_columns), a typical workflow with three steps, and security guidance on using parameterized queries. It implicitly suggests usage for complex queries but does not explicitly contrast with sibling tools like filter_sql_query for simpler needs.
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?
No annotations are provided, so the description carries the full burden. It describes the return format and mentions prerequisites, but does not explicitly state that the operation is read-only, safe, or idempotent. It also lacks details on error handling or rate limits, which is adequate but not thorough.
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 well-structured with clear sections (main purpose, prerequisite, workflow, see also, args, returns). It is concise, using bullet points and no redundant text. The main purpose 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 simple nature of the tool (one parameter, read-only list), the description covers the essential workflow, prerequisites, and return format. It could include more detail on potential errors or edge cases, but it is complete enough for most use cases.
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?
The input schema has zero description coverage, but the description compensates by documenting the parameter doc_id as 'L'ID du document' in the Args section and explaining how to obtain it via list_documents. This adds meaningful context beyond the raw schema.
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 lists all tables in a Grist document ('Liste toutes les tables dans un document Grist'). It distinguishes from sibling tools like create_table and filter_sql_query by mentioning them in 'see also' and providing a workflow that positions this tool after list_documents and before list_columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides prerequisites (list_documents to get doc_id) and a typical workflow (1. list_documents, 2. list_tables, 3. list_columns). It also lists alternative tools (create_table, filter_sql_query) in 'see also', giving clear guidance on when to use this tool versus others.
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?
With no annotations provided, the description carries the full burden of disclosure. It explains the action (upload), lists all parameters with meanings, and describes the return structure (status, message, ID). It does not cover potential error cases or permissions, but the basic behavioral traits are well communicated.
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 concise and well-structured: a one-sentence overview, a prerequisite section, a clear args list, and a returns statement. No redundant information; every sentence serves a purpose.
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 tool's complexity (4 parameters, no nested objects), the description covers the essential aspects: what it does, prerequisites, parameter meanings, and return type. It is missing details like file size limits or error handling, but the presence of an output schema reduces the burden on the description.
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?
Despite 0% schema description coverage, the description provides explicit explanations for all four parameters (doc_id, filename, content_base64, content_type), adding meaning beyond the schema's type-only definitions. It lacks details on constraints like file size or default values, but overall significantly enhances parameter understanding.
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 'Téléverse une pièce jointe dans un document Grist', which is a specific verb+resource. It is distinct from sibling tools like download_attachment and list_attachments, making the purpose immediately identifiable.
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 a prerequisite ('list_documents to get a doc_id'), which guides the user on necessary prior steps. However, it does not explicitly mention when not to use this tool or provide alternatives, though the context of sibling upload/download tools implies usage.
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?
No annotations are provided, so the description carries the full burden. It details the return value (dict with status, message, details) and parameters. It does not explicitly mention destructive behavior or authorization, but the creation nature is clear.
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 long but well-structured with sections (description, prerequisites, workflow, args, returns, examples). It is front-loaded with purpose and each section adds value.
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 complexity (11 parameters, 0% schema coverage), the description is very complete. It explains all parameters, provides examples, and notes the return format. An output schema exists but the description adds context.
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 description coverage is 0%, so the description must compensate. It explains each parameter, lists supported types for column_type, explains choices, visible_col, etc. This adds significant meaning beyond the schema.
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 states 'Crée une nouvelle colonne dans une table.' This is a specific verb and resource, and it is distinct from sibling tools like create_table or create_document.
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 prerequisites (list_tables) and a typical workflow (1. list_tables, 2. create_column, 3. list_columns). It does not explicitly mention when not to use this tool or alternatives, but the context is clear.
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?
No annotations are provided, so the description carries the full burden. It states that the tool creates a workspace and returns a dict with status, message, and ID. However, it does not discuss idempotency, duplicate handling, or side effects. The behavioral transparency is adequate but not thorough.
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 well-structured with sections for prerequisites, workflow, args, and returns. It is concise without unnecessary words, and the main purpose is front-loaded in the first line. Every sentence adds value.
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's low complexity (2 required parameters) and the presence of an output schema, the description is complete. It explains prerequisites, workflow, parameter semantics, and return format. No gaps are apparent for effective use.
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?
With 0% schema description coverage, the description must compensate. It provides natural language explanations for both parameters: 'org_id: L'ID de l'organisation' and 'name: Nom du nouvel espace de travail'. This adds clear meaning beyond the schema's type definitions, though it could include format constraints or examples.
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 creates a new workspace in an organization ('Crée un nouvel espace de travail dans une organisation.'). This is a specific verb+resource pair that distinguishes it from sibling tools like delete_workspace or list_workspaces.
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?
The description explicitly provides prerequisites (list_organizations to get an org_id) and a typical workflow (list_organizations, create_workspace, list_workspaces). It tells the agent when to use this tool and suggests verification steps.
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?
No annotations provided, so description carries full burden. It describes the core behavior of deleting history and preserving 'keep' recent actions. It could mention permanence or permissions, but overall sufficient for a delete operation.
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?
Concise single paragraph with clear purpose, then structured 'Args' and 'Returns' sections. No wasted words.
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?
Covers input parameters and return type. Mentions use case. Could include an example or state that operation is irreversible, but overall adequate for a simple deletion tool.
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 description coverage is 0%, but the description fully explains both parameters: doc_id as document ID, keep as number of recent actions to retain with default 1000. Adds value beyond the bare schema.
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?
Clearly states it deletes document history while keeping recent actions. Distinguishes from sibling delete_document by specifying it targets history only. Also provides a use case: reducing large document size.
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?
Explicitly mentions it is useful for reducing size of large documents, giving clear context. However, it does not explicitly compare to alternatives or state when not to use it.
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?
No annotations provided. The description implies a read operation (list) but does not explicitly state it is non-destructive or mention side effects, auth needs, or rate limits. It returns a dict but lacks explicit safety guarantees. Adequate but could improve.
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?
Well-structured with clear sections (prerequisite, workflow, see also, args, returns). Every sentence adds value. Front-loaded with main purpose. No unnecessary fluff.
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's simplicity, the description covers usage context (prerequisite, workflow), relationships to siblings, and return format. Output schema exists but description already explains returns. Complete for a list tool.
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 0%, so description must compensate. It explains org_id as 'entier ou sous-domaine string' (integer or string subdomain), adding meaning beyond the schema's anyOf type constraint.
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 'List all workspaces in a Grist organization' (specific verb+resource). It distinguishes from siblings like describe_workspace (details) and create_workspace (creation).
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 prerequisites (org_id from list_organizations), a typical workflow (1,2,3), and explicit alternatives via 'See also' (create_workspace, describe_workspace, modify_workspace_access). Agents can clearly decide 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?
No annotations are provided, so the description carries the full burden. It states that records are updated and returns a dict with status, message, and IDs, but it does not disclose failure behaviors, side effects, or authorization requirements. Basic mutation transparency is present, but lacks depth.
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 well-structured with sections: verb statement, prerequisites, workflow, args, and returns. Every sentence is useful and front-loaded with purpose, achieving conciseness without waste.
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 tool's moderate complexity (3 params, return object), the description covers prerequisites, workflow, parameter formats, and return values. It lacks error handling details, but is fairly complete for its scope. Output schema exists, so return explanation is adequate.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter (doc_id, table_id, records) and provides a concrete example for the records parameter, adding meaning beyond the raw schema types.
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 updates existing records in a Grist table, using a specific verb and resource. It distinguishes from siblings like add_grist_records and delete_grist_records by its focus on updates.
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?
The description explicitly lists a prerequisite (list_records to obtain IDs) and provides a typical two-step workflow. This guides the agent on when and how to use it, and implies it requires prior listing.
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?
No annotations provided, so description carries full burden. It states the tool creates a document and returns status, message, and ID. No side effects or destructive behavior mentioned, but that is expected. Lacks permission or error details, still transparent enough.
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?
Description is well-structured with sections: summary, prerequisites, workflow, args, returns. Every sentence adds value, no redundancy. Front-loaded with the core action.
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 tool's simplicity and presence of an output schema, the description covers creation, prerequisites, and expected returns. It misses error handling or validation details, but is complete enough for typical use.
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 description coverage is 0%, so description must add meaning. It explains workspace_id as workspace ID and name as document name. The workflow further clarifies context. Provides sufficient semantics beyond the raw schema.
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 creates a new document in a workspace, distinguishing it from sibling tools like delete_document or modify_document. The verb 'Crée' and resource 'document' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists prerequisite (list_workspaces) and a typical three-step workflow. This guides the agent on when and how to use the tool, though it doesn't specify when not to use it—which is acceptable for a creation 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?
In the absence of annotations, the description warns that the action is irreversible and deletes all associated data. It does not cover permissions or side effects like impact on references, but the warning provides sufficient transparency for a delete operation.
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 concise, starting with a clear purpose, then a structured Args/Returns section. No unnecessary words, and every sentence adds value.
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?
For a delete tool, the description covers the irreversible nature, parameter identification, and return format. With no output schema, the stated return type ('Dict with status and message') is adequate. No critical gaps remain.
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?
The input schema lacks descriptions (0% coverage), but the description provides a clear list of parameters (doc_id, table_id, column_id) with brief explanations of what each represents. This compensates fully for the schema gap.
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 'Supprime une colonne d'une table' (delete a column from a table). This distinctively identifies the action and resource, differentiating it from sibling tools like create_column or modify_column.
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 includes an 'Attention' warning about irreversibility and data loss, guiding cautious use. Although it does not explicitly compare to alternatives, the context makes the use case unambiguous among siblings.
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?
No annotations provided, so description fully shoulders the burden. It states it deletes records (destructive) and returns a status/confirmation. Could mention irreversibility or authorization, but the deletion behavior is fairly transparent.
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?
Well-structured with sections: main description, prerequisites, workflow, args, returns. Front-loaded with purpose. Concise without superfluous text.
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 simplicity (3 params, no nested objects, output schema present), the description fully covers prerequisites and workflow, enabling correct tool invocation.
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 has 0% coverage, so description must compensate. It lists each arg with a brief explanation: doc_id as document ID, table_id as table ID, record_ids as list of IDs to delete. This adds meaning beyond the bare schema types.
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 deletes records from a Grist table, using a specific verb and resource. It is distinct from sibling tools like add_grist_records, update_grist_records, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides prerequisites (list_records to obtain IDs) and a typical workflow (list then delete). This gives clear guidance on when to use this tool and its dependency.
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?
No annotations provided, so description carries full burden. It discloses the simplified interface, return type (dict with records and metadata), and usage patterns. However, it does not explicitly state if the operation is read-only, but the context implies it is non-destructive.
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 well-structured with sections (prerequisites, alternatives, workflow, use cases, args) and front-loaded with the main purpose. However, it is somewhat lengthy; a few sentences could be trimmed without losing value.
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 presence of an output schema (as indicated by context signals), the description adequately covers return information. It provides comprehensive context: prerequisites, workflow, use cases, and detailed parameter explanations, making it complete for a filtering query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates by explaining each parameter in detail with concrete examples (e.g., where_conditions dict, order_by syntax, limit for pagination). This adds significant meaning beyond the input schema.
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 a SQL filter query on a Grist table, emphasizes it's a simplified version for common queries without writing SQL, and distinguishes from siblings like list_records and execute_sql_query.
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 by contrasting with list_records and execute_sql_query, recommends prerequisites (list_tables, list_columns), and includes a typical workflow and specific use cases.
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?
The description details the return value (dict with success, message, schema) and the frictionless format. However, it does not explicitly state that the operation is read-only or safe, though inferred. No annotations are present to contradict.
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 efficiently structured with sections for prerequisites, workflow, see also, args, and returns. Every sentence serves a purpose; no redundancy.
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 simplicity of the tool (2 required params, no annotations), the description fully covers how to use it, prerequisites, and the return format. The presence of an output schema is acknowledged in the description.
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?
The input schema has no descriptions (0% coverage). The description adds clear explanations for both parameters: 'doc_id: L'ID du document' and 'table_id: L'ID de la table', which compensates for the schema gaps.
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 action 'obtient le schéma détaillé' and the resource 'table Grist'. It distinguishes itself from sibling tool 'list_columns' which provides a simpler list.
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?
Prerequisites are specified (use list_tables first) and a typical workflow is provided. The 'Voir aussi' section explicitly directs to an alternative tool for simpler needs.
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?
No annotations provided, but description discloses the return structure (success, message, documents) and parameter requirement. It does not mention side effects or permissions, but as a read-only list operation, this is adequate.
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 well-structured with clear sections (prerequisites, workflow, see also, args, returns) and is concise without superfluous information.
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's low complexity, one parameter, and an output schema that documents return values, the description is fully complete. It covers all necessary aspects for correct usage.
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 0%, but the description adds a brief explanation for the only parameter: 'workspace_id: L'ID de l'espace de travail'. This adds meaning beyond the schema's type definition.
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 lists all documents in a Grist workspace, using a specific verb ('Liste') and resource ('documents'). It distinguishes from siblings like create_document, describe_document, and modify_document_access.
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 prerequisites (list_workspaces), a typical workflow, and references to related tools under 'Voir aussi'. It gives clear context on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns a dict with success, message, and organizations, implying a read-only operation. However, it does not mention potential pagination or limitations, but given the simplicity (no parameters), the disclosure is sufficient.
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 well-structured with separate sections for prerequisites, workflow, and returns. It is concise, with every sentence providing value, and front-loads the main purpose.
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?
For a parameterless tool with an output schema described in the description, the description is complete. It covers purpose, usage, behavior, and return format, leaving no significant gaps.
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?
No parameters exist, so schema coverage is 100%. The description adds meaning beyond the schema by specifying the return value fields (success, message, organizations), which is helpful for understanding the output.
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 all accessible Grist organizations, with a specific verb ('Liste') and resource ('organisations'). It distinguishes itself from siblings like list_workspaces by positioning as the main entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites ('Aucun') and provides a typical workflow showing list_organizations as the first step, followed by list_workspaces. This gives clear guidance on when and how 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?
No annotations are provided, so the description carries the full burden. It describes the return structure (success, message, document) and implies a read-only operation, but does not explicitly state side effects or authentication requirements. Slightly lacking for full transparency.
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 concise and well-structured, with a clear first line stating purpose, followed by prerequisites, workflow, args, and returns. Every sentence adds value.
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's simplicity (one parameter, no annotations, output described in returns), the description covers all necessary aspects: purpose, prerequisites, workflow, parameter meaning, and output structure. It is complete for an agent to use correctly.
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 description coverage is 0%, but the description clarifies the parameter 'doc_id' as 'L'ID du document à décrire' and ties it to the prerequisite, providing full meaning beyond the schema.
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 that the tool obtains detailed information about a specific document, using a specific verb and resource. It distinguishes itself from sibling tools like create_document, delete_document, etc., by focusing on reading and describing.
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?
The description explicitly provides a prerequisite (list_documents to get a valid doc_id) and a typical workflow (1. list_documents, 2. describe_document), guiding the agent on when and how to use this tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it explains prerequisites, parameter behavior, and return format (base64 encoded content). There are 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose sentence, then sections for prerequisites, args, and returns. Every sentence adds value without redundancy.
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's complexity (3 parameters, output schema exists), the description is complete: prerequisites, parameter explanations, and return format. It covers what an agent needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining each parameter: doc_id (document ID), table_id (optional, defaults to first table), header (value options: label, id, none). This adds meaning beyond the schema.
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 downloads a Grist document in Excel format. It is specific with verb and resource, and distinguishes from siblings like download_document_sqlite and download_table_csv by specifying the format.
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 a prerequisite (list_documents to get valid doc_id), indicating when to use this tool. It does not explicitly mention alternatives for other formats, but the sibling list implies these exist.
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?
The description explains the return structure (success, message, columns) and implies a read operation. While no annotations exist, the description is transparent about behavior, though it does not explicitly state it is read-only.
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?
Structured with clear sections (Prérequis, Flux de travail typique, Voir aussi, Args, Returns), every sentence is informative and no excessive wording, making it concise yet complete.
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's simplicity and the presence of an output schema, the description covers prerequisites, workflow, parameters, and returns comprehensively, leaving no gaps for an AI agent.
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?
With 0% schema coverage, the description adds meaning by defining parameters ('doc_id: L'ID du document', 'table_id: L'ID de la table') and integrates them into the workflow, fully compensating for the schema's lack of details.
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 'Liste toutes les colonnes dans une table Grist', providing a specific verb ('list') and resource ('columns'), and distinguishes it from siblings like 'create_column' by specifying the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists prerequisites ('list_tables'), provides a typical workflow (1. list_tables, 2. list_columns, 3. list_records), and references alternative tools ('create_column', 'modify_column') under 'Voir aussi', guiding 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description reveals the return structure (dict with success, message, records, record_count) and implies read-only behavior via 'Liste'. It lacks explicit statements about side effects or error handling, but the return structure adds transparency.
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 well-organized with sections: introductory sentence, Prérequis, Flux de travail typique, Voir aussi, Args, Returns. It is concise and every sentence adds value without redundancy.
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 simplicity of the tool (list records with optional sort/limit) and the presence of an output schema, the description covers prerequisites, workflow, parameters, return format, and alternatives. It is fully self-contained for an agent to use correctly.
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 description coverage is 0%, so the description carries the full burden. It explains all four parameters: doc_id, table_id, sort (with format), and limit (with purpose). This adds meaning well beyond the schema types and defaults.
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 verb 'Liste' and the resource 'enregistrements dans une table Grist' with optional sorting and limiting. It distinguishes itself from siblings by referencing alternatives like filter_sql_query and add_grist_records.
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?
The description provides prerequisites (list_tables), a typical workflow (list_tables -> list_columns -> list_records), and alternatives (filter_sql_query for advanced filtering, add_grist_records for adding). This gives clear guidance on when to use this tool versus others.
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:

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

Score Badge

Copy to your README.md:

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

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

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