SmartSuite MCP Server

Server Quality Checklist

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

Latest release: v0.9.8
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., list vs. describe vs. create for forms, automations, views, dashboards). Even similar tools like search_records and query_records have clear differences in purpose and parameters.
Naming Consistency4/5
Names consistently use the verb_noun pattern with underscores (e.g., list_forms, create_record). Some variation exists (get vs. describe, add vs. create), but it follows logical categories and is predictable.
Tool Count4/5
83 tools is a large number, but it is justified by the comprehensive scope of the SmartSuite platform, covering CRUD, automation, dashboards, file handling, schema migration, and more. The count is on the higher side but not excessive for the domain.
Completeness5/5
The tool set covers the full lifecycle: CRUD for solutions, applications, records, fields, views, forms, automations, and dashboards, plus utilities like file upload, attachment moves, formula analysis, and schema diffs. No obvious gaps in functionality.
Average 4.4/5 across 83 of 83 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 5 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on July 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
The description adds no behavioral information beyond the annotations (readOnlyHint=true). It does not disclose traits like rate limits or result format.
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 a single, clear sentence with no unnecessary words. It is appropriately concise.
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 minimal and does not mention pagination or additional context, though the schema covers parameters. Given no output schema, it could be more 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter meaning or context 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 verb 'list' and the resource 'comments on a SmartSuite record'. It is specific and distinguishes from sibling tools like smartsuite_create_comment.
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 or when not to. No alternatives or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims to 'persists the lower→prod table-id map into the project', indicating a write operation. However, annotations declare readOnlyHint=true, a direct contradiction. Description contradicts annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in two sentences, front-loading its purpose. However, it could better structure the flow description and explicitly mention prerequisites.
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 adequately places this tool in a multi-step migration process and explains why name matching is necessary. However, the contradiction with annotations undermines trust, and no output schema or return value details are provided.
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 coverage is 100%, so baseline is 3. The description adds no new parameter details beyond the schema, merely referencing the 'confirm/overrides flow'. It does not explain parameter formats or constraints beyond what the schema provides.
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 role as 'Step 2 of solution migration', matching tables (applications) by exact name. It distinguishes from the sibling 'match_solutions' by specifying it operates on the table level within a confirmed solution pair.
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 implies this tool is used after match_solutions, stating 'for one confirmed solution pair'. It references the 'same confirm/overrides flow as match_solutions', providing context but no explicit when-not-to-use 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?
Annotations already declare readOnlyHint=true, so the description's contribution is minimal. It adds no additional behavioral context such as performance implications, rate limits, or edge cases. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of 10 words, with no extraneous information. It is appropriately concise for a simple tool, though it could benefit from slightly more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (2 required) and no output schema, the description is somewhat minimal. It does not describe the return format or pagination behavior, but the tool's purpose is straightforward enough that the description is adequate.
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 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, meeting the baseline expectation.
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 ('Search records'), the resource ('records'), and the scope ('using a text query across specified fields'). It effectively distinguishes this from sibling tools like 'list_records' or 'get_record' by focusing on text-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for full-text search but does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'list_records' or 'query_records'). No when-not-to-use or alternative references are included.
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 explicitly states that the tool does not replace existing content, which adds behavioral information beyond the readOnlyHint annotation (false). However, it does not disclose potential side effects, error conditions, or rate limits, leaving gaps in 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 extremely concise with only two sentences, each serving a distinct purpose: stating the action and mode requirement, and clarifying behavioral impact. 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?
Given the tool's simplicity and lack of output schema, the description covers the core purpose and mode requirements. However, it omits details about response format, error scenarios (e.g., invalid field or record), and the confirm parameter's role, leaving some ambiguity for the agent.
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 coverage is 100%, so the input schema already describes all parameters. The tool description does not add any additional parameter-level meaning beyond what is in the schema, leading to a baseline score of 3.
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 the tool appends markdown content to a SmartDoc field, distinguishing it from sibling tools like smartsuite_get_smartdoc_content. The verb 'append' and resource 'SmartDoc field' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions that readwrite or admin mode is required, providing some usage context. However, it does not specify when to use this tool over alternatives, nor does it provide 'when-not-to-use' guidance. Additional context on when to prefer appending versus overwriting would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool writes diff.json (a side effect), contradicting the readOnlyHint=true annotation. This is a serious inconsistency, per rules scoring 1 for contradiction.
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 detailed but each sentence adds value. It is front-loaded with purpose and logically sequenced. Slightly long but justified by complexity; could be broken into structured points.
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 complex tool with no output schema, the description covers classification of changes and file output. It lacks specifics on summary format but is mostly complete given the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds valuable context beyond schema, such as how fields match by slug and remapping of cross-table references. This enhances understanding of parameter effects.
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 compares table/field schemas and writes a diff package, distinguishing it from siblings like smartsuite_match_solutions. It specifies it is Step 3 of solution migration and details what it diffs based on 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 explains the tool's role in a migration sequence and provides clear scope options (all vs schema). However, it does not explicitly state when not to use it or mention alternatives, but the context is sufficient for selection.
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 aligns with the readOnlyHint annotation, indicating a safe read operation. However, it adds no additional behavioral context such as rate limits, authentication requirements, or error handling beyond what annotations already provide.
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 extremely concise at one sentence, with no filler. It is front-loaded with the core action. However, it could be slightly expanded to include usage context without losing brevity.
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 get-by-ID tool with well-documented parameters and a readOnlyHint, the description is fairly complete. It does not describe return values or error scenarios, but this is typical and acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, adequately explaining all four parameters (recordId, applicationId, fields, includeFieldContext). The tool description adds no further parameter 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 verb 'Get', the resource 'single SmartSuite record', and the identifier 'by ID'. It is specific and distinguishes from sibling tools like smartsuite_list_records and smartsuite_search_records.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage when a record ID is known, but does not mention alternatives or exclusions.
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?
The annotations already declare readOnlyHint: true, confirming this is a safe read operation. The description adds no further behavioral context (e.g., no mention of side effects, rate limits, or response structure). Since annotations suffice, the description provides minimal added value beyond confirming the read-only nature.
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 two sentences: the first states the purpose and method, the second provides a crucial prerequisite action. It is front-loaded and contains no redundant information. Every sentence earns its place.
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 has nested parameters (filter object) and no output schema. The description correctly advises on prerequisite knowledge (field slugs) but does not explain the response format, pagination behavior, or how the filter object maps to results. While parameter documentation is thorough, the overall behavior remains somewhat opaque without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88% (7 of 8 parameters have descriptions), so the schema already explains most parameters. The description does not add parameter-specific details beyond the overall purpose. It includes a hint about field slugs, which is indirectly useful but not parameter-specific. Baseline 3 is appropriate given the high schema coverage.
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 ('Query records') and the resource ('using a structured SmartSuite filter'). This distinguishes it from sibling record tools like smartsuite_list_records (which lists all records) and smartsuite_search_records (which likely uses search syntax). The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Use smartsuite_describe_application first to learn field slugs and valid values for choice fields', providing a clear prerequisite. However, it does not specify when not to use this tool versus alternatives like smartsuite_list_records or smartsuite_search_records. The guidance is helpful but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, so the description does not need to repeat that. It adds no extra behavioral traits beyond the annotations.
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 a single sentence with no superfluous words, conveying the necessary info efficiently.
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 read operation with one parameter and no output schema, the description is adequate. It clearly states the tool fetches details for a specific solution, which is complete for its simplicity.
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 100% schema description coverage for the single parameter (solutionId), the description does not add meaning beyond the schema's 'The solution ID'. Baseline score of 3 is appropriate.
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 'Get' and the resource 'details for a specific SmartSuite solution', distinguishing it from sibling tools like smartsuite_list_solutions (which lists all solutions) and smartsuite_create_solution (which creates).
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 provide guidance on when to use this tool versus alternatives like smartsuite_list_solutions. It only states the function without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which the description aligns with. The description adds no additional behavioral traits beyond what annotations provide. No contradiction.
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?
Single sentence of 10 words with no fluff. Front-loaded with the key action and resource. Every word earns its place.
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 2 optional parameters and no output schema, the description is sufficient. It clearly explains what the tool does. Could mention pagination behavior but schema covers that.
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 100% for both parameters (limit, cursor). The description does not add any new meaning beyond the schema; baseline score of 3 applies.
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 ('List'), the resource ('SmartSuite solutions (workspaces)'), and the scope ('accessible to the authenticated user'). It is specific and distinct from sibling tools like smartsuite_get_solution and smartsuite_create_solution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when needing a list of solutions) but does not provide explicit guidance on when not to use or mention alternatives. It is adequate but lacks depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Persists to a project mapping file,' indicating a write operation, but annotations declare readOnlyHint=true. This is a clear contradiction. Beyond that, the description does not disclose potential side effects, authorization requirements beyond the environment variable, or what happens to existing data. The contradiction severely undermines trust.
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 dense but every sentence adds value. It starts with purpose, then usage steps, then parameter roles, and finally side effect. No fluff. The structure is logical 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?
Given the tool's complexity (migration step with two modes), the description covers workflow, parameters, and high-level output categories (exact/ambiguous/unmatched). However, it lacks details on the exact return structure (e.g., schema of proposed matches) and does not specify what the mapping file looks like. Without an output schema, some agents might need more detail, but the description is adequate 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?
Schema coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema: it explains the two-step workflow (propose vs confirm), how overrides resolve ambiguous/unmatched matches, and the role of nameFilter. This contextual information helps an agent understand parameter interplay.
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 as 'Step 1 of solution migration: match solutions in a lower-environment workspace to those in your primary (production) workspace by exact name.' It distinguishes from sibling tools like smartsuite_list_solutions and smartsuite_match_applications through the specific migration 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 explains when to use this tool (as part of a migration workflow) and provides step-by-step guidance: set primary workspace, call without confirm to propose matches, then with confirm and overrides to finalize. It mentions a prerequisite (SMARTSUITE_ENABLE_CROSS_WORKSPACE) and that source workspace must differ from primary. However, it does not explicitly state when not to use or list 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?
The description notes the non-read-only nature (consistent with annotations) and adds mode prerequisites. However, it does not disclose side effects, error handling, or the return format, which limits transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover purpose, prerequisites, and a usage tip. No redundant 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's simplicity, the description includes key context (mode, prerequisite) and is complete enough for basic use. The lack of output schema details is a minor gap, but the prerequisite guidance adds value.
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 100%, so the description does not add meaning beyond what is already in the schema. The mention of field values keyed by slug is already present in the field's description.
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 record in a SmartSuite application, with a specific verb and resource. It distinguishes itself from siblings like update_record and delete_record by focusing on creation.
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 specifies required access mode (readwrite or admin) and suggests calling smartsuite_describe_application first to learn field slugs. This provides clear context for usage, though it does not explicitly mention when not to use or list alternatives.
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 discloses read-only behavior (consistent with annotations) and adds specific metadata included in the response, which is valuable given no output schema. However, it doesn't reveal potential errors 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 a single sentence that efficiently conveys the main purpose and key metadata categories with no wasted words. It is front-loaded and easily digestible.
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 no output schema, the description usefully lists several metadata fields returned. However, it may not be exhaustive (e.g., missing default values, field type). For a complex tool interacting with SmartSuite, slightly more detail would improve completeness.
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 already describes both parameters with 100% coverage. The description does not add extra meaning or usage hints beyond what the schema provides, so the baseline score of 3 is appropriate.
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 retrieves detailed metadata for a single field, listing specific metadata types (help text, choice options, linked-record targets, formula expression/return type). This distinguishes it from sibling tools like smartsuite_list_fields, which lists fields without such detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining detailed field metadata but provides no explicit guidance on when to choose this over alternatives (e.g., smartsuite_list_fields for summaries). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds rich detail about what is returned (settings, sharing, page layout with bound fields and content elements, conditional visibility). No contradictions. Provides significant context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads purpose and then lists details. Is somewhat long but each element is relevant. Could be split into two sentences for readability, but overall efficient.
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?
No output schema exists, yet description fully covers return structure: top-level categories (settings, sharing, page layout) and nested elements (bound fields, content elements, conditional flags). Complete for a read tool with two parameters.
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 coverage is 100% with basic descriptions of formId and applicationId. The description does not add additional semantic meaning for parameters; it focuses on output. Baseline 3 is appropriate.
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 'Get the full structure of a SmartSuite form for review' and enumerates elements (settings, sharing, page-by-page layout). Distinguishes from sibling tools like smartsuite_list_forms, which likely returns only metadata.
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?
Implies usage for review/diagnostics by describing the output, but does not explicitly state when to use versus alternatives or provide exclusions. Siblings include mutations (create, update, submit) and listing, so context hints at read-only usage, but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description need not repeat that. It adds value by explaining the scoping per solution (not per table) and listing the returned attributes, which is useful context beyond the annotation.
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?
Two sentences, front-loaded with purpose, no redundant information. Every sentence contributes meaningful detail (scope and return fields).
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 enumerates return fields, compensating for the lack of an output schema. It clarifies scope and contrasts with per-table scoping. However, it omits details like pagination or limits, which are minor given the tool's simplicity.
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 already fully documents the single parameter ('solutionId') with a description. The tool description reiterates 'solution' but adds no additional parameter-specific semantics, so baseline 3 applies.
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 automations for a solution, specifies the scope (per solution, not per table), and enumerates the return fields (id, name, etc.). It uses a specific verb and resource, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing automations per solution but does not explicitly contrast with sibling tools like smartsuite_describe_automation or smartsuite_create_automation. No when-not-to-use guidance is 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?
Annotations already declare readOnlyHint, so the read-only mention is redundant. The description adds useful behavioral context about returned fields and permission respect, but lacks details on pagination behavior beyond 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?
The description is concise (4 sentences) and front-loaded with purpose. Every sentence adds value, with 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 no output schema, the description adequately explains return fields and suggests follow-up use. Missing details like sorting or limits, but sufficient for a list 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 coverage is 100%, so baseline 3. The description repeats some schema info (required solutionId, optional applicationId, cursor for pagination) but adds minimal new meaning. No significant extra value.
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 soft-deleted records in a solution's trash, specifying it as read-only. It distinguishes from sibling tools by focusing on deleted records and clarifying solution-scoped 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 explicit guidance: solution-scoped, optional applicationId filter, and relevance to smartsuite_restore_records. It could improve by contrasting with list_records for non-deleted records, but overall good.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the tool is read-only. The description adds behavioral context by listing the specific fields returned (id, name, description, page count, etc.) and the usage scenario. It does not mention pagination or limits, but the read-only nature reduces the burden.
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 two sentences, front-loading the main purpose and returned fields, then adding context. Every sentence adds value, with 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?
With one required parameter, no output schema, and readOnlyHint annotations, the description explains the output fields and usage context. It lacks detail on error handling or pagination, but for a simple list operation, it is largely 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 only parameter 'applicationId' is described in the schema as 'The application ID.' The description adds no new semantics beyond mentioning 'for a SmartSuite application.' Since schema coverage is 100%, baseline is 3; no additional value.
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 forms (form-type report views) for a SmartSuite application.' It specifies the verb 'List', resource 'forms', and provides context. It distinguishes from sibling tools like smartsuite_describe_form by detailing the returned fields and usage in ITSM dashboards.
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 forms are used for record submission and are launched from button-row widgets in ITSM dashboards, but it does not explicitly state when to use this tool versus alternatives like smartsuite_describe_form. No when-not-to-use guidance is 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?
Annotations declare readOnlyHint=true, so the description does not need to re-state safety. It adds token-saving tips but no additional behavioral traits like pagination behavior or rate limits. The description contributes marginal value beyond the annotations.
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 three sentences, each earning its place: purpose, prerequisite, optimization tip. No wasted words, clearly front-loaded, and efficiently structured.
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 read-only list tool with 8 parameters and no output schema, the description covers the response format (json vs compact), pagination (cursor), and a helpful prerequisite. It is mostly complete but could mention error handling or rate limits.
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 high (88%), so the baseline is 3. The description adds usage advice (e.g., using compact format and fields projection to save tokens) but does not significantly enhance parameter meanings beyond what the schema already provides.
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 records from a SmartSuite application' with a specific verb and resource. It also hints at a prerequisite using another tool, which adds clarity. Although siblings like smartsuite_search_records exist, the purpose is unambiguous and well-defined.
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 advises using smartsuite_describe_application first to learn field slugs and recommends using format:"compact" with a fields projection for large result sets. It provides clear context on when to use certain parameter options but does not exclude alternative tools like search_records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint false, consistent with mutation. The description adds beyond annotations by disclosing dry-run support and permission requirements, but does not detail error handling or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. All information is front-loaded and relevant.
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 purpose, basic usage, and constraints (permissions, dry-run). Lacks output information and error scenarios, but sufficient for a batch update tool with no output schema.
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 coverage is 100% with descriptions for all parameters. The description adds no parameter-level details beyond restating dry-run mode, so baseline 3 is appropriate.
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 'Batch update multiple records', specifying the verb ('update') and resource ('multiple records'). It distinguishes from siblings like smartsuite_update_record (singular) and smartsuite_create_records (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions dry-run mode and required permissions ('readwrite or admin mode'), which provide context but does not explicitly state when to use this tool over alternatives like smartsuite_update_record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint: false, so it is a write operation. The description adds context: file is read locally and posted as multipart form data, and requires specific authorization modes. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences (31 words) directly state the purpose, prerequisites, and mechanism. No extraneous 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 5 parameters, no output schema, and simple operation, the description covers core behavior. It could mention success/failure responses or size limits, but is adequate for an agent to understand the tool's role.
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 coverage is 100%, so the schema already documents all parameters. The description adds minimal additional meaning beyond 'file is read from the local path,' which is already reflected in the filePath parameter description.
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 specifies the action ('Upload a file'), the source ('local filesystem'), and the destination ('SmartSuite file field'), clearly distinguishing it from siblings like smartsuite_get_file_url (download) and smartsuite_move_attachments (move).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisite mode ('Requires readwrite or admin mode') but provides no guidance on when to use this vs. alternatives, nor when not to use it. Usage is implied but not explicit.
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?
Beyond annotations (readOnlyHint: false), the description adds critical behavioral details: it is a write operation, requires specific permissions, defaults to preview unless confirm:true, and explains how sections group subsequent fields. This goes well beyond the annotation, though it doesn't cover side effects like order changes.
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 moderately concise and well-structured, starting with purpose, then requirements, then behavior and parameter usage. Each sentence adds value, but it could be slightly more compact without losing clarity.
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 no output schema and 8 parameters, the description covers the tool's purpose, effect, parameter usage, and prerequisites. It is complete enough for an agent to use the tool correctly, though it does not describe return values (acceptable without 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 coverage is 100%, but the description adds meaningful context for key parameters like afterField (placement logic), confirm (dry-run vs apply), and tabId (layout targeting). This enhances understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a section (a labeled grouping) to an application's record-view layout,' specifying the verb (add), resource (section), and target (record-view layout). It distinguishes from siblings like smartsuite_update_layout_section by focusing on addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (readwrite/admin mode, SMARTSUITE_ENABLE_SCHEMA_WRITE) and explains positioning behavior, but does not explicitly guide when to use this versus alternatives like update_layout_section or remove_layout_section. It provides context but lacks direct when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare 'readOnlyHint: true', so the description adds only the output format ('plain text and raw value'). No additional behavioral traits are disclosed beyond what annotations provide.
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 a single, focused sentence with no wasted words. It is front-loaded with the main purpose and immediately states the output type.
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 read operation on a SmartDoc field, the description together with the schema covers all necessary information: what it does, what it returns, and the required input parameters. No output schema is needed for such a straightforward 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 coverage is 100% with each parameter having a description. The tool description does not add any new meaning beyond the schema's parameter descriptions, so it meets the baseline of 3.
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 uses a specific verb 'Retrieve' and specifies the resource 'SmartDoc field' and the output format 'plain text and raw value'. It clearly distinguishes from sibling write tools like 'smartsuite_append_smartdoc_content'.
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 implies when to use the tool (to retrieve SmartDoc content) but does not explicitly state when not to use it or mention alternatives. However, the context is clear and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description aligns by describing a list operation and adds output details (id, integration, etc.), but does not disclose additional behavioral traits beyond what annotations offer.
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?
Two sentences efficiently cover what the tool does, examples, return fields, and usage purpose. No wasted words.
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 no output schema, the description fully explains the return value and use case. No gaps.
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 100% with a single parameter described as 'The solution ID.' Description does not add extra meaning beyond the schema; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists integration credentials for a solution's automations, naming specific examples (Gmail, Slack, etc.) and return fields (id, integration, auth method, label). Distinguishes from sibling 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?
Explicitly says 'Use this to review which external integrations a solution's automations connect to,' providing clear context. No exclusions or alternatives mentioned, but the purpose is well-defined.
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 confirms the write operation (consistent with readOnlyHint=false) and adds the mode requirement, providing behavioral context beyond annotations. No side effects or response details are mentioned, but the core behavior is 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 two sentences, front-loaded with the primary action. Every sentence adds value: the first states what the tool does, the second adds a critical usage constraint. No unnecessary 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?
For a simple create tool with three parameters and no output schema, the description covers the purpose and access requirement. It lacks return value or success behavior, but given the simplicity, it is nearly 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?
Schema coverage is 100%, and the description does not add any additional meaning or formatting guidance beyond the schema's parameter descriptions. The baseline of 3 is appropriate as the schema already documents the parameters adequately.
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 ('Add a comment') and target ('to a SmartSuite record'), with a specific verb and resource. It distinguishes from the sibling tool 'list_comments' by focusing on creation.
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 specifies a prerequisite ('Requires readwrite or admin mode'), guiding when the tool can be used. However, it does not provide explicit guidance on when to use this tool over alternatives (e.g., other add-content tools) or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the agent knows this is a write operation. The description adds context: it checks label uniqueness, validates field slugs against the application schema, and supports a dry-run mode. These details go beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph. It covers all critical information without unnecessary fluff. While not broken into sections for readability, it is concise and front-loaded with the core action and prerequisites.
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?
With 9 parameters and no output schema, the description omits what the tool returns (e.g., the created form object or ID). It covers creation behavior and prerequisites well but lacks completeness on return value, which could hinder agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds value by explaining the uniqueness constraint on label, the validation of field slugs, and the semantics of the confirm parameter (dry-run vs. create). This supplements the schema's parameter 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?
Clearly states 'Create a new form for a SmartSuite application.' The verb and resource are explicit, and the function is distinct from sibling tools like smartsuite_list_forms or smartsuite_update_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites: 'Requires readwrite/admin mode AND SMARTSUITE_ENABLE_SCHEMA_WRITE=true.' Also explains the dry-run behavior vs. actual creation via the confirm parameter. However, it does not explicitly mention when not to use or list 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description reinforces that this is a read operation by stating 'Get'. It adds specific behavioral context by detailing what the full configuration includes (trigger, actions, name, enabled state, timezone), which goes beyond the annotation to give agents a clear picture of the output. 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 two sentences long, front-loaded with the primary purpose, and contains no extraneous words. Every sentence serves a clear function: stating what the tool does and providing a usage hint.
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 essentials for a describe tool: what it returns and how to obtain the required ID. While there is no output schema, the description mentions the key fields. Given the tool's simplicity and the presence of good annotations, it is sufficiently 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?
Schema coverage is 100%, with both parameters (solutionId, automationId) described in the input schema. The description does not add further semantics beyond the schema, but the schema itself is clear. Given high coverage, a score of 3 is appropriate.
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 'Get' and the resource 'automation', listing the specific components returned (trigger config, action groups, name, enabled state, timezone). It also distinguishes from the sibling tool smartsuite_list_automations by directing users to use that for finding automation IDs.
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 instructs users to use smartsuite_list_automations to find automation IDs before calling this tool, providing clear context for usage. It does not mention when not to use it, but for a describe tool that depends on knowing the ID, this guidance is sufficient.
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 adds value beyond the readOnlyHint by detailing the return structure (fields and tab list). It does not contradict annotations and provides useful behavioral context.
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?
Two sentences with no wasted words: first sentence defines purpose and output, second gives alternative. Ideal conciseness and structure.
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 required parameter and no output schema, the description is sufficient. It covers the return fields and offers an alternative. Minor omission of pagination/ordering details, but not critical.
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 only parameter, applicationId, is fully described in the schema. The description adds no further semantic meaning, so baseline 3 is appropriate given 100% schema coverage.
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 resource 'dashboards for a SmartSuite application', and specifies the returned fields (id, name, description, order, tab count, tab list). This distinguishes it from sibling tools like smartsuite_describe_dashboard.
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 suggests an alternative tool (smartsuite_describe_dashboard) for branding and widget detail, guiding when not to use this tool. However, it does not mention other scenarios or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true. The description goes beyond by specifying exact return fields (id, name, recordTerm) and the important limitation that restore is not available via API. This adds valuable behavioral context without contradiction.
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?
Three sentences, no wasted words. The first sentence states the core purpose, the second lists outputs, and the third provides essential caveat. Structure is front-loaded and all sentences earn their place.
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 (one param, read-only, no output schema), the description covers the essential: what it lists, what it returns, and what it cannot do. It lacks mention of pagination or error scenarios, but for a basic listing tool this is sufficient.
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?
There is only one parameter (solutionId) with 100% schema description coverage. The description does not add extra meaning beyond the schema's 'The solution ID whose deleted applications to list.' Since schema carries the burden, a baseline of 3 is appropriate.
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 'list soft-deleted applications in a solution's trash' with a precise verb and resource. It distinguishes from listing active applications by explicitly stating 'deleted' and 'in trash', and differentiates from other deletion-related tools via the 'read-only' and 'listing only' qualifiers.
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 clear context on when to use: to view deleted applications. It adds critical guidance by noting that no public restore endpoint exists, nudging the agent toward UI restore. While it does not explicitly list alternatives, the sibling set includes 'list_applications' for active ones, which is implicitly contrasted. This is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that the API does not attribute deleted fields to their source application (so no app filtering), and that it returns slug, label, and fieldType. This provides useful behavioral context beyond the annotation. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each conveying essential information. The first sentence states purpose and read-only nature. The second specifies return fields. The third adds scope limitation and a pointer to restore tool. No unnecessary words.
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 has only one parameter and no output schema, the description covers all essential aspects: what it does, what it returns, its scope, a limitation, and a related action. It is fully informative 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter solutionId, with a clear description. The description does not add any additional parameter details beyond the schema, so it meets the baseline but does not exceed it.
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 soft-deleted fields, is read-only, and returns specific data. It distinguishes from active field listing tools (smartsuite_list_fields) by focusing on deleted fields and mentioning solution-scoping. The verb 'List' with resource 'soft-deleted fields' is specific.
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 context for when to use this tool: to see deleted fields. It mentions that results are not filtered by app, which sets expectations. It also suggests the next step of restoring with smartsuite_restore_field. However, it does not explicitly exclude other alternatives beyond the scope limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds details about the response (summary, items, truncated preview) and defaults. No contradictions. Additional context like overdue counts and breakdowns is provided.
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 two sentences, efficiently delivering purpose and key details. It is front-loaded with the main action and includes examples. Could be slightly more concise, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no required ones, and no output schema, the description covers the main points (defaults, summary, item types). However, it lacks details on response structure beyond summary and items, and some parameter interactions (e.g., period with resolved) could be clearer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds value by noting the default behavior (open items, limit 50) and how summary reflects full filtered set, which is not in the schema. Some parameter details (like period with resolved) are only implied.
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 the authenticated user's assigned work, specifies item types (comment mentions, checklist items, records) and gives example questions. It uniquely identifies its purpose among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains default behavior (open items) and how to get completed work (status:resolved). It provides example questions, giving context for use. However, it does not explicitly exclude cases or compare to alternative 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?
Annotations indicate readOnlyHint: true, and the description adds contextual use cases (automation, resolving IDs) without contradicting. No hidden side effects are implied.
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?
Two sentences with no fluff. The first sentence delivers the core purpose and output, the second adds practical usage context. Information is front-loaded and 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?
For a simple read operation with one parameter, the description sufficiently explains the tool's function and relevance. Missing details like result limits or filtering are acceptable given the tool's straightforward nature.
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 sole parameter (solutionId) is described in the schema as 'The solution ID'. The description does not add new constraints or format details beyond what the schema provides, so it adds minimal value.
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 (list), resource (solution members), and returned fields (id, name, email, job title, status). It differentiates from sibling tools by noting its utility for resolving member IDs and supporting automations.
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 states when to use: to view members for automation assignment or to resolve IDs from records. While it doesn't specify when not to use, the context makes it clear this is the tool for listing solution members.
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?
Adds detail beyond annotations: requires schema-write (mutation), dry-run behavior, and non-destruction of fields. Annotations indicate destructive, but description clarifies scope.
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?
Three concise sentences, front-loaded with purpose. No unnecessary words, every sentence adds value.
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 key aspects: purpose, effect, permission, preview behavior. Lacks error conditions or exact slug format, but sufficient for an AI to use correctly.
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 coverage is 100%, so baseline 3. Description adds minimal extra meaning: slug pattern 'section__…' and confirm default false. Does not add to other 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?
Clearly states verb 'Remove', resource 'section from layout', and identifier 'section__… slug'. Distinguishes from sibling tools like 'add_layout_section' and 'update_layout_section' by specifying it removes only the grouping, preserving fields.
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 context: requires 'schema-write' permission, explains dry-run preview unless confirm=true, and clarifies that fields are preserved. Does not explicitly state when not to use, but the distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so description adds the mode requirement and return value ('Returns the updated item'). It provides behavioral context beyond annotations without contradiction.
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?
Two sentences front-load the core action, then provide prerequisites and outcome. Every word is necessary and 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?
For a simple update tool with three parameters and no output schema, the description covers purpose, prerequisites, and return value. It lacks error handling or edge cases but is sufficient for a typical use case.
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 100%, so parameters are well-documented. The description summarizes the actions (mark resolved/open, set due date) but adds minimal new 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 updates 'My Work items' with specific actions: marking resolved/open and setting due date. It uses a specific verb ('Update') and resource ('My Work items'), distinguishing it from siblings like smartsuite_list_my_work.
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 specifies required mode ('readwrite or admin mode') and directs to use smartsuite_list_my_work to find the item ID. While it lacks explicit when-not-to-use or alternatives, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Behavior is consistent with annotations (readOnlyHint=false indicates mutation). The description adds context about required access mode and partial update behavior, which annotations do not cover. No contradiction.
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?
Two sentences, front-loaded with core purpose, no unnecessary words. Every sentence provides value.
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 an update tool with no output schema, the description covers mode requirement and partial update best practice. It does not specify return value, but this is not critical given lack of output schema. Adequate for the complexity.
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 coverage is 100% with descriptions for all three parameters. The description does not add new parameter information beyond what the schema already provides, so baseline applies.
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 'Update an existing record,' which is a specific verb+resource combination. This distinguishes it from sibling tools like create_record, list_records, and delete_records.
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 usage context: 'Requires readwrite or admin mode' and advises 'Only supply fields you want to change,' which implies partial updates. However, it does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, which is obvious for a creation tool. The description adds critical behavioral context: required permissions, environment variable, default 'Title' field creation, and dry-run preview unless confirm:true. No contradictions with annotations.
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?
Three concise sentences: first states purpose and prerequisites, second lists inputs, third describes default field and dry-run behavior. No redundancy, front-loaded with essential information.
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?
While the description explains the action and side effects well, it does not mention what is returned on success (e.g., the created application object or a confirmation). Given no output schema, a hint about return value would improve completeness. However, it does describe dry-run output and references sibling tools for further steps.
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 covers all parameters with descriptions (100% coverage). The description adds value by clarifying the dry-run behavior and the default field, which enhances understanding beyond the schema. Baseline 3; extra context justifies 4.
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 table (application) in a solution, using specific verb and resource. It distinguishes from sibling tools like smartsuite_create_field (adds fields) and smartsuite_create_solution (creates solution).
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 (readwrite/admin mode and env variable) are explicitly stated. It specifies required inputs (name, solutionId) and the dry-run behavior via confirm parameter. It also references smartsuite_create_field for adding more fields. Missing explicit 'when not to use' but overall strong guidance.
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 configuration components returned (filters, sort, etc.), adding behavioral context beyond the readOnlyHint annotation. No output schema exists, but the listed items give a good sense of the response.
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 two sentences: the first states the purpose and lists outputs, the second gives a usage hint. No unnecessary words, efficiently 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 read operation with well-documented parameters and annotations, the description covers purpose, output components, and a prerequisite step (list_views). It is complete for effective agent use.
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 100% for both parameters, so the baseline is 3. The description does not add parameter-specific details beyond the schema, but it implies the role of viewId and references list_views for obtaining it.
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 gets the full configuration for a single SmartSuite view, listing specific components (filters, sort, group-by, etc.). It distinguishes from sibling tools like smartsuite_list_views and the create/update/delete view 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 explicitly advises to use smartsuite_list_views to find view IDs, providing a prerequisite. It could also mention when not to use this tool (e.g., if only needing a list of views), but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that the result is 'stable within a session — call once per table and reuse it,' which is a useful behavioral trait beyond the annotation's scope.
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?
Two sentences contain all essential information: output details, exclusions, usage guidance, and caching hint. No unnecessary words.
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 read-only listing tool with one parameter and no output schema, the description fully covers purpose, content, exclusions, and caching behavior. Nothing significant is missing.
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 100% schema description coverage (schema already describes applicationId as 'The application ID'), the description adds no additional semantic information for the parameter. Baseline 3 is appropriate.
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 specifies the exact action ('List a SmartSuite application's fields'), the resource (fields), and the output structure ('slug, label, type, choice options, linked-app targets'), explicitly stating what is omitted. This distinguishes it from sibling smartsuite_describe_application.
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 states to prefer this tool over smartsuite_describe_application when only field slugs/types/choices are needed, providing clear context. However, it does not specify when not to use it (e.g., when help text is needed), but the guidance is strong.
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?
Discloses mutation (annotations confirm readOnlyHint:false), details effect on layout's hidden_fields list, record-wide scope, and preview mode. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, requirements, and behavior. Front-loaded with main action, then details.
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 inputs and behavior well, though no output schema means return values are not described. Still sufficient for a mutation tool with clear inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining behavioral impact of hidden (true/false) and confirm, e.g., 'hidden:true hides the field (adds it to the layout's record-wide hidden_fields list).'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Hide or show a field in the record view.' with specific verb and resource, distinguishing it from siblings like smartsuite_delete_field or smartsuite_create_field.
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?
Description specifies required permissions ('readwrite/admin + SMARTSUITE_ENABLE_SCHEMA_WRITE'), explains dry-run behavior unless confirm:true, and notes that hiding is record-wide. Lacks explicit when-not-to-use, but context is clear.
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?
Describes return values (validity, complexity, structural metrics, dependency graph, impact index) and notes extra API calls for deep:true. Annotations already indicate read-only, no contradiction.
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?
Efficiently organized by mode, though packed with details. Could be slightly more concise but well-structured.
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?
No output schema, but description comprehensively details return values for both modes. Covers edge cases (deep:true) and format (ASCII tree, Mermaid flowchart).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline 3. Adds extra meaning: fieldSlug triggers full detail+dependency graph, sortBy ignored when fieldSlug set, deep:true triggers heavier computation.
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 two modes: summary of all formula fields (without fieldSlug) and detailed analysis of one formula (with fieldSlug). Distinguishes from siblings like smartsuite_validate_formula and smartsuite_create_formula_field.
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?
Explains when to use each mode and the deep parameter. Lacks explicit 'when not to use' but context is sufficient.
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?
Beyond the already-present readOnlyHint=true annotation, the description reveals that limit is enforced client-side because the API ignores it, and that the response includes a total count. This adds useful behavioral context about the actual behavior of the limit parameter.
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: three sentences covering purpose, filtering, return shapes, and a performance warning. Every sentence earns its place, with no redundant or vague wording.
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 list tool with no output schema, the description adequately covers both return shapes and the total count. It could be improved by mentioning whether pagination (e.g., offset) is supported, but it already explains the limit behavior and provides enough for most 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?
All three parameters have schema descriptions (100% coverage). The description adds further value by explaining the effect of slim (compact vs full objects) and the client-side enforcement of limit, which are not in the schema. The explanation of slim's recommendation for multi-table solutions is particularly helpful.
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 starts with 'List SmartSuite applications (tables)', a clear verb+resource pair. It distinguishes from sibling list tools like smartsuite_list_forms and smartsuite_list_automations by specifying the resource type and noting optional filtering by solution.
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 actionable guidance by noting the default 'heavy' return and recommending the slim:true option for multi-table solutions to avoid token budget issues. It does not explicitly state when not to use the tool or compare to alternatives, but the context is clear enough.
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?
The description discloses that files are copied without re-upload (reference existing storage), that the source is cleared by default, that mode can append or replace, and that there is a dry-run mode unless confirm:true. It also mentions a cap on records. This provides full insight into the tool's behavior, matching the readOnlyHint=false annotation.
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 a single dense paragraph that efficiently communicates all key points. It front-loads the purpose and then details options. While it could be more structured (e.g., bullet points), it is concise and contains no wasted words.
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 most behavioral aspects but does not explicitly state the return value or output format. Since there is no output schema, the agent is left to infer the response (likely success/result or preview data). Given the complexity (8 params, mutation tool), this omission is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 8 parameters. The description adds context beyond the schema, such as 'handles reference existing storage — no re-upload' and the dry-run behavior, but the schema already explains individual parameters well. The description adds overall behavioral context but not per-parameter detail.
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 'move' and the resources 'attachments' and 'file fields'. It explains the core action: copying files from one field to another and optionally clearing the source. This distinguishes it from sibling tools like smartsuite_upload_file or smartsuite_create_record.
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 specifies required access mode ('readwrite/admin'), explains when to use recordId vs allRecords, and describes the mode (append/replace) and clearSource options. It also mentions the dry-run behavior. It lacks an explicit 'when not to use' statement, but the instructions are clear and the tool is unique among siblings.
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?
Discloses destructive behavior ('cannot be undone'), preview mode without confirm, and required permissions (readwrite/admin mode, env vars). Adds value beyond readOnlyHint: false annotation, with 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?
Three concise sentences, each serving a purpose: action, prerequisites, and detailed behavior. No unnecessary words, front-loaded with primary 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?
Covers purpose, prerequisites, confirm behavior, and destructiveness. Lacks detail on return value (preview output), but no output schema exists. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions in schema already cover widgetId and confirm. The description repeats confirm's dry-run behavior but does not add new information beyond schema. With 100% coverage, baseline of 3 is appropriate.
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 ('Remove a widget from a dashboard'), matches the tool name, and distinguishes from sibling tools like add/update/delete widgets. It also specifies prerequisites and destructive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance, including required mode and environment variables, and explains the confirm parameter for preview vs. permanent delete. Does not explicitly mention alternatives but context is sufficient.
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?
Adds valuable behavior beyond destructiveHint annotation: fields remain, last tab disables tabs, dry-run preview mode, and authentication requirement. No contradiction with annotations.
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?
Three efficient sentences, front-loaded with core purpose. 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 key behavioral aspects and requirements for a simple tool with no output schema. Minor omission of error handling or behavior on missing tab, but generally 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?
Schema coverage is 100% so parameters are well-documented. Description adds meaning for confirm (dry-run preview) but no extra detail for tabId or applicationId beyond 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 the tool removes a tab from a record-view layout by tab id. Differentiates from siblings like smartsuite_add_layout_tab and smartsuite_remove_layout_section.
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?
Specifies prerequisites (schema-write), confirms dry-run preview by default, and covers edge case (last tab disables tabs). Does not explicitly contrast with alternatives but context is sufficient for most agents.
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?
Discloses schema-write permission and dry-run mechanism beyond annotations (which only indicate non-read-only). Also notes clearing description with empty string. Adds useful behavioral context.
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?
Three concise sentences with no superfluous content. Front-loads purpose and key constraints. Excellent economy of 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 essential behavioral aspects (preview, permission, clearing description) despite no output schema. Could be slightly more detailed on return value but adequate given 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?
Schema coverage is 100% (baseline 3). Description adds semantic value by explaining dry-run via confirm param and clearing description with empty string, which are not fully captured in 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?
Clearly states verb (update), resource (layout section), and specific attributes (title, description, collapsed, hidden). Distinguishes from sibling tools like add_layout_section.
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 context on permission requirement ('Requires schema-write') and preview behavior ('Dry-run preview unless confirm:true'). No explicit when-not or alternatives, but enough guidance for typical use.
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 only readOnlyHint=false in annotations, the description fully discloses key behaviors: requires schema-write permission, dry-run preview unless confirm:true, and the ability to clear description by passing empty string. This significantly aids agent decision-making.
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?
Three concise sentences, each adding distinct value: operation, permission, and behavioral note. No fluff, front-loaded with essential 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?
Adequately complete for a mutation tool with no output schema. Covers permission, preview mode, and clearing description. Could mention error handling or side effects of reordering, but not required.
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 coverage is 100% and each parameter is well-described. The description adds minimal new semantic information beyond grouping the parameters. Baseline 3 is appropriate.
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 updates a record-view tab, specifies the updatable attributes (name, description, position, style/align), and uses the tab id. It differentiates from sibling tools like add_layout_tab and remove_layout_tab by focusing on update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: requires schema-write, dry-run unless confirm:true. However, it does not explicitly exclude other tools or mention when to use alternatives like add_layout_tab or remove_layout_tab.
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?
Annotations only provide readOnlyHint=false, so the description carries the full burden. It discloses the required readwrite/admin mode and environment variable, explains credentialId propagation, describes two action passing formats, and notes optional fields. This adds significant behavioral context beyond what annotations offer.
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 a single paragraph of moderate length, front-loaded with the core purpose and prerequisites. It is efficient without unnecessary repetition, though it could benefit from bullet points or more structured formatting for high scanability.
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 (nested objects, optional parameters, alternative inputs), the description covers prerequisites, shape discovery, action formats, credential propagation, and optional fields. It does not detail return values or errors, but lacks output schema and sibling tools cover those aspects. Overall, it is fairly complete for a create 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 100%, but the description adds meaning: it explains the mutual exclusivity of 'actions' and 'actionGroups', how 'credentialId' fills gaps, and that 'automaticDescription' is a phrase-builder JSON string. This clarifies usage beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create an automation in a solution' with a specific verb and resource. It distinguishes itself from sibling tools like smartsuite_update_automation and smartsuite_describe_automation by being the only creation tool for automations, making intent 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 (readwrite/admin mode, SMARTSUITE_ENABLE_SCHEMA_WRITE=true) and recommends using smartsuite_describe_automation_step for learning trigger/action shapes. It covers key usage context but does not explicitly state when not to use this tool (e.g., for updates vs creation), though it is implied.
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?
The description adds significant behavioral context beyond the readOnlyHint=false annotation: it specifies authentication mode requirements, the dry-run/confirm two-phase execution model, respect for SMARTSUITE_MAX_BATCH_WRITES, and return values (IDs and per-row failures). No contradiction with annotations.
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?
Four sentences, front-loaded with purpose, each sentence adding value. No filler. Efficient and clear.
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?
Despite no output schema, the description covers return values, prerequisites, batch limits, and workflow. For a batch create tool with 4 parameters, this is comprehensive.
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 coverage is 100%, so baseline is 3. The description adds the dry-run/confirm workflow context but doesn't significantly elaborate on individual parameter formats beyond what the schema provides. The mention of 'field values keyed by slug' is already in 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 'Batch-create multiple records in one call.' This is a specific verb+resource, and the name 'smartsuite_create_records' distinguishes it from the singular 'smartsuite_create_record' and other siblings like 'smartsuite_update_records'.
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: requires readwrite/admin mode, dry-run workflow, batch-size cap respect, and a prerequisite to call smartsuite_describe_application. It lacks explicit when-not-to-use guidance, but the name and context suffice.
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?
Annotations already indicate destructiveHint=true; the description expands on this by detailing soft-delete to trash, mode and env var requirements, dry-run support, return value (deleted recordIds), and recoverability via other tools. No contradiction with annotations.
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 two sentences long, front-loads critical information (soft-delete, mode, env var), and avoids redundancy. 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 no output schema, the description covers prerequisites (mode, env var), behavior (soft-delete, dry-run), return value (recordIds), and recovery options. For a delete tool with five parameters, this is comprehensive and contextually 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?
Schema description coverage is 100%, so baseline is 3. The description adds minimal parameter-specific context beyond mentioning dry-run support; the schema already covers all parameter meanings adequately.
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 tool deletes records via soft-delete to the trash, specifies required mode and environment variable, and distinguishes itself from siblings by referencing recovery and listing tools. This provides a clear and specific purpose.
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 mentions required mode and env var, supports dry-run, and names alternative tools for recovery and listing, giving good context on when to use this tool versus alternatives. It does not explicitly state when not to use, but the alternatives imply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the bar is lower. The description adds that the tool creates files (XLSX, JSON) and returns their paths, which is useful behavioral context beyond what annotations convey. Could be more explicit about the operation being 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the step number and key purpose. Every sentence earns its place, providing purpose, format details, prerequisite, and return 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 tool with no output schema, the description adequately explains that it returns file paths. It also specifies the output formats and the prerequisite. Given the tool's role in a multi-step process, the description is 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?
Schema coverage is 100%, so the schema already describes both parameters (format and project). The description does not add extra meaning beyond the schema, which is adequate given the baseline for high coverage.
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 renders a project diff as XLSX and JSON, specifies it's Step 4 of solution migration, and names a prerequisite (smartsuite_diff_schemas). This distinguishes it from sibling tools like form or record operations.
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 advises to run smartsuite_diff_schemas first, providing clear sequential context. Also mentions it returns file paths, helping the agent understand what to expect after invocation.
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 discloses the return fields (plan category, limit, used, remaining, percent, enforce flag) beyond the readOnlyHint annotation. It adds context about what the tool reports, though it doesn't discuss permissions 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?
The description is two sentences, front-loading the purpose and then listing return fields. Every sentence earns its place 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?
For a no-parameter read-only tool without output schema, the description fully covers the return data and usage context. It is complete for the agent to understand what the tool does and what it returns.
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?
There are no parameters, and schema coverage is 100%. The description adds value by explaining what the response will contain, which is useful despite the lack of params.
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 retrieves the workspace's automation run usage and plan limit. It distinguishes itself from sibling automation tools like smartsuite_list_automations or smartsuite_describe_automation by focusing on quotas and plan limits.
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 provides use cases: 'how much of our automation quota are we using?' and plan-type questions. While it doesn't mention when not to use it, the context is clear enough for the agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; the description adds that the URL is temporary and signed, reinforcing the read-only nature. No destructive behavior is implied, and no contradictions exist.
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 three sentences long, front-loaded with the core purpose, and provides necessary context without extraneous detail. 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 output schema, no nested objects), the description fully explains what the tool does, how to use it, and provides an example. Annotations complement it 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?
The parameter fileHandle is fully described in the schema (100% coverage). The description adds context by explaining that it comes from the 'handle' property of file field objects and provides an example, which adds 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 the tool resolves a file handle to a signed CDN download URL, specifies the source (SmartSuite file fields), and provides an example. This is specific and distinct from sibling 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?
It explains when to use the tool (after obtaining a file handle from a file field) and implies a specific use case (downloading). However, it does not explicitly mention when not to use or list alternatives, though the sibling smartsuite_upload_file is clearly opposite.
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?
Beyond annotations, the description fully discloses the two-step workflow, validation behavior (required fields, field membership), and the need for readwrite/admin mode. No annotation contradiction.
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 two sentences to convey purpose, workflow, validation, and auth. Front-loaded with the primary action.
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?
While the description covers the process and constraints, it omits details about the return value shape for both steps (preview and submission). Given no output schema, this is a notable gap for an agent expecting a response.
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 already covers all parameters (100% coverage). The description adds value by integrating the parameters into the two-step process, explaining the role of 'values' omission for preview, and clarifying that values use slug keys and record shapes.
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 submits a SmartSuite form to create a record, exactly as a user filling out the form. It distinguishes from sibling tools like direct record creation by emphasizing the form pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two-step usage pattern (call without values to preview, then with values to submit) and mentions authentication mode. However, it does not explicitly contrast with alternative tools like direct record creation or other form actions.
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?
Annotations only provide readOnlyHint=false, so the description must disclose behavioral traits. It does so thoroughly: explains that params is replaced wholesale, that updating params can reset widget height (advising to also pass size), and that position uses columns for x and pixels for y. This adds significant value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then lists modifications concisely. It contains all necessary warnings and explanations in a single paragraph. While slightly long (5 sentences), every sentence adds essential context. Minor redundancy in listing 'settings' and then enumerating them, but overall 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 10 parameters, no output schema, and nested objects, the description covers the main use cases, prerequisites, side effects, and references a companion tool. It explains the critical params replacement and height reset. Lacks information on return value or error handling, but completeness is high for a mutation 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 100%, so baseline is 3. The description adds meaning by clarifying the coordinate units (x/width columns, y/height pixels), the replacement behavior of params, and linking tabId to moving widgets. It doesn't detail every parameter but compensates for nested objects and complex behaviors.
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 updates a dashboard widget's settings and/or layout, listing specific attributes (position, size, name, color, etc.). It distinguishes itself by being the update counterpart to add/remove widgets, though it doesn't explicitly contrast with siblings. Still, purpose is unmistakable.
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 states the required mode (readwrite/admin) and environment variable (SMARTSUITE_ENABLE_SCHEMA_WRITE=true). Provides guidance on updating params (read first, pass full object) and warns about height reset. Does not explicitly list when NOT to use it or compare to alternatives, but context is clear.
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?
The description discloses side effects such as enabling tabs if not already on, first tab mirroring layout, and dry-run preview. This adds context beyond the readOnlyHint=false annotation, without contradiction.
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 a single, dense paragraph that efficiently conveys all necessary information. It is front-loaded with the core action, though the detail could be slightly more structured.
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 lack of output schema, the description thoroughly explains what the tool does, including dry-run behavior and tab enabling logic. It covers all 7 parameters and their interplay comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by explaining that 'position' is 0-based, 'style' is for tab-bar, 'align' is container-level, and 'confirm' is required to apply. It also notes that description is optional.
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 'Add a tab to an application's record-view layout' with a specific verb and resource, and it distinguishes this tool from siblings like smartsuite_remove_layout_tab and smartsuite_update_layout_tab.
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?
It explicitly mentions requirements: 'Requires readwrite/admin mode AND SMARTSUITE_ENABLE_SCHEMA_WRITE' and explains the dry-run behavior. However, it does not explicitly state when not to use it or provide alternatives.
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?
Discloses validation before creation, automatic slug generation, and dry-run functionality. Annotations only indicate write intent; description adds critical behavioral traits.
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?
Four sentences, no fluff. Purpose and prerequisites in first sentence. Logical flow from requirements to behavior. Every sentence adds value.
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 auth, dry-run, validation, and slug. No output schema, so description could hint at return value for confirm:true, but overall adequate for a moderately complex 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 covers all parameters. Description adds meaning: formula validation purpose, slug auto-generation, confirm toggling dry-run, and afterFieldSlug placement logic. Goes beyond 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?
Verbs 'create' and resource 'formula field' are explicit. Distinguishes from siblings like smartsuite_create_field and smartsuite_update_formula_field by specifying field type and concurrency.
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?
Specifies required modes (readwrite/admin) and environment variable. Explains dry-run vs actual creation with confirm parameter. No explicit when-not-to-use, but context is clear.
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?
The description discloses behavioral traits beyond annotations: requires specific mode and environment variable (readwrite/admin mode, SMARTSUITE_ENABLE_SCHEMA_WRITE=true), explains that the server assigns slug, default logo, and permissions, and details the dry-run preview unless confirm:true. This adds significant context missing from annotations.
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 highly concise and front-loaded. The first sentence states the core action and prerequisites. Subsequent sentences add essential details about required/optional parameters, related tools, and confirm flag behavior. Every sentence contributes meaning without 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 lack of an output schema, the description adequately covers the creation process, permissions, and usage pattern. It could optionally mention what a dry-run preview returns, but overall it is sufficiently complete for an agent to invoke this 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 already covers all parameters with descriptions (100% coverage). The description adds value by clarifying that only name is required, that logoIcon and logoColor are optional, and explaining the confirm parameter's effect (dry-run vs actual creation). This provides context 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 'Create a new solution' with specific action and resource. It distinguishes from sibling tools by referencing smartsuite_create_application for adding tables, and includes necessary context like permission requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that only a name is required, optional parameters (logoIcon, logoColor), and the dry-run behavior controlled by the confirm flag. It also mentions that tables are added via another tool (smartsuite_create_application), providing usage guidance. However, it does not explicitly state when to use or avoid 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description reveals the dry-run behavior with confirm:false and confirms permanence. It also mandates specific modes and env vars, adding critical context.
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?
Three sentences with zero waste. Each sentence serves a distinct purpose: action and prerequisites, preview vs. delete behavior, and destructiveness warning.
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?
No output schema, but the description explains what happens (delete or preview) and prerequisites. It lacks details on the preview return format, but given the tool's simplicity, it is mostly 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?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the confirm parameter's default (false = preview) and its effect, which is not evident from the schema alone.
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 'Delete an automation,' clearly indicating the action and resource. It distinguishes from sibling tools like update, create, describe, and list.
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 specifies prerequisites (readwrite/admin mode, environment variables) and explains the confirm parameter's role (preview vs. actual delete). However, it does not mention alternatives or when not 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive, but the description adds 'removes the field and its data' and explains the dry-run preview behavior via the confirm parameter. No contradictions with annotations.
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 a single, dense paragraph with no unnecessary words. It front-loads the tool's purpose and efficiently covers prerequisites, behavior, and an example.
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 no output schema, the description adequately covers prerequisites, destructive behavior, dry-run mechanism, and a use case. It could mention the response or success indication, but overall is sufficiently 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?
Schema covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds value by explaining the confirm parameter's role in dry-run vs actual deletion, going 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 starts with 'Delete a field from a table by slug', clearly stating the verb and resource. It distinguishes itself from sibling tools like create_field, update_field, and restore_field by specifying the destructive nature and the refusal of system fields.
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 required modes and environment variables, and provides a concrete use case (replacing a formula field with a rollup). It does not explicitly mention alternatives, but the context makes it clear when to use vs other field operations.
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?
Annotations already mark it as readOnlyHint=true. The description adds that it does not return the API key, a key behavioral guarantee. It also discloses what it returns (server version, mode, account info), providing full transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, and every word adds value. No 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?
For a diagnostic tool with no parameters and annotations present, the description is complete in telling what it does and returns. It could mention error behavior or typical use case, but current level is adequate.
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?
There are zero parameters and schema coverage is 100%, so description needs no parameter details. The baseline for no-parameter tools is 4, and the description adds no extra parameter info because none needed.
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 validates SmartSuite MCP server configuration and connectivity, specifying returns of version, mode, and account info. This distinguishes it from all sibling tools which focus on data operations like records, forms, or automations.
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 implies usage for validating server setup and connectivity, but does not explicitly mention when not to use or alternatives. However, given the unique diagnostic purpose among siblings, context is sufficiently clear.
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?
Annotations indicate readOnlyHint: false, confirming it's a write operation. The description adds important details: required permissions, the ability to remove logic via clear:true, and the dry-run behavior (preview unless confirm:true). It also explains the conditions structure and common comparisons. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It includes an example and lists common comparisons. Slightly long but all sentences earn their place. Minor reduction due to length but no 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?
Given the complexity (7 parameters, nested conditions, three target types), the description covers behavior, permissions, and usage patterns. It does not mention return values, but that is acceptable since no output schema exists. Overall, it is complete enough 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 coverage is 100%, so baseline is 3. The description goes well beyond the schema by explaining target types (field slug, section__ slug, tab id), conditions array format with example, common comparisons, and the clear/confirm flags. This adds significant value for an agent.
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 the verb 'Add, modify, or remove' and the resource 'display (visibility) logic on a field, section, or tab', with the specific purpose 'show it only when conditions on other fields are met'. This clearly distinguishes it from sibling tools like smartsuite_set_field_visibility, which likely handles static visibility instead of conditional logic.
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 clear context: it's used for conditional visibility, requires readwrite/admin + SMARTSUITE_ENABLE_SCHEMA_WRITE, and mentions dry-run preview unless confirm:true. It gives an example and lists common comparisons. However, it does not explicitly contrast with smartsuite_set_field_visibility 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotation readOnlyHint=false, the description discloses the tabs replacement behavior (including destructive deletion of widgets), the merging of footer/style, and required permissions. This provides comprehensive behavioral context.
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 approximately 150 words, well-structured with clear explanations of each updatable aspect. It front-loads the main purpose and elaborates on parameters efficiently, avoiding 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's complexity (8 parameters, nested objects) and no output schema, the description covers permissions, parameter behavior, and cross-tool references. It is nearly complete; only missing an explanation of the return value, which is not required per rubric.
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 100%, so the baseline is 3. The description adds extra value by explaining the tabs replacement semantics (full list required, id usage for rename/add/remove) and merge behavior for footer/style, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a dashboard' and lists specific updatable components (label, description, tabs, footer, style). It distinguishes the tool from sibling update tools (e.g., update_form) by focusing on dashboard-specific properties.
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 specifies prerequisites (readwrite/admin mode and SMARTSUITE_ENABLE_SCHEMA_WRITE=true) and gives guidance on obtaining tab IDs from smartsuite_describe_dashboard. However, it does not explicitly state when not to use this 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, and the description elaborates on the write behavior, including dry-run preview, confirm to apply, and the advanced formState escape hatch. 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 a single paragraph that efficiently covers requirements, options, and behavior. Every sentence adds value without 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 10 parameters, nested objects, and no output schema, the description covers primary behaviors and the dry-run mechanism. It lacks return value details but is adequate for agent 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 50% description coverage; the description adds meaning by explaining settings merging, fields replacement, and formState wholesale replacement. It compensates for missing schema descriptions on parameters like title, submitLabel, etc.
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 'Update a form's settings and/or structure.' It specifies what can be updated (settings, fields, formState) and distinguishes from sibling tools like list, describe, create, submit forms.
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 (readwrite/admin mode, SMARTSUITE_ENABLE_SCHEMA_WRITE=true) and explains the dry-run vs apply flow via confirm parameter. It does not explicitly state when not to use, but the alternatives are implied by sibling tool names.
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?
Discloses numerous behaviors: default position appends below, template filling for params, column/pixel units, default sizes per type, accent color defaults, and specific notes for summary-card/chart. All beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, but quite verbose. Information is valuable and logically ordered, but could be more concise.
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?
Covers all aspects: prerequisites, defaults, special cases (summary-card, chart), and error conditions. No output schema but mentions response field. Complete for tool complexity.
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?
Adds rich meaning beyond schema: explains widget type categories, layout units, defaults, and optional template filling. Compensates for schema's lack of enum values.
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 action and resource: 'Add a widget to a dashboard tab.' Distinguishes from sibling tools like update and remove.
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 prerequisites (readwrite/admin mode, env var) and provides extensive how-to guidance. Lacks explicit when-not-to-use but context clarifies purpose.
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?
The description openly discloses key behaviors: dry-run capability (unless confirm:true), label uniqueness check (with alternative suggestion), and the requirement for readwrite/admin mode and the environment variable. These details go beyond the annotations (readOnlyHint: false) and provide actionable 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 (3-4 sentences) and well-structured: it starts with the primary purpose, followed by prerequisites, behavior notes, and a sibling reference. 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?
For a creation tool with no output schema, the description adequately covers inputs, behavior (dry-run, uniqueness), and outcome (creation or preview). It also provides a logical next step (adding widgets). No missing critical information is apparent.
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?
While the input schema covers all 5 parameters with descriptions, the description adds meaningful semantics: it explains the dual type for tabs (strings or objects) and the default tab behavior, clarifies the confirm parameter's dry-run effect, and emphasizes label uniqueness checks. This enhances understanding 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 ('Create a dashboard in an application'), specifies the resource ('dashboard') and context ('in an application'), and differentiates from sibling tools like smartsuite_add_dashboard_widget by noting it is used afterward.
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 clear context for when to use the tool (creating a dashboard) and prerequisites (readwrite/admin mode and environment variable). It also guides the agent on post-creation steps (use smartsuite_add_dashboard_widget). However, it does not explicitly state when not to use it or compare with similar creation 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?
Annotations already indicate readOnlyHint=false, so description confirms it's a write operation. Adds significant behavioral context: dry-run preview, auto-filling type defaults, auto-creation of backlinks, AI prompt handling. These go beyond the annotation.
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?
Description is lengthy but well-structured, front-loading the core purpose. Uses bullet-like examples and conditional sections. Every sentence conveys necessary information 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 (7 params, nested objects, many field types), the description is remarkably thorough. Covers prerequisites, default behaviors, field-type-specific parameters, AI fields, and layout placement. No output schema, but description compensates with operation details.
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 100% but the description provides extensive, type-specific guidance for the params field (e.g., choices format for select fields, linkedrecordfield requirements, rollup/lookup syntax). Also explains the aiPrompt parameter in depth.
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 opens with 'Create a field of any type in an application' and lists many field types including rollup/lookup. It distinguishes from sibling tool smartsuite_create_formula_field by explicitly noting formula fields are handled elsewhere.
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?
Clearly states prerequisites (readwrite/admin mode and SMARTSUITE_ENABLE_SCHEMA_WRITE=true). Provides guidance on when to provide params ('only where they matter') and when to use the sibling tool for formulas. Also mentions dry-run preview unless confirm:true.
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?
Beyond the readOnlyHint=false annotation, the description discloses behavioral traits: required mode/env var, label uniqueness validation with alternative suggestion, dry-run preview unless confirm:true, field slug validation against schema. No annotation contradiction.
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 given the tool's complexity. It fronts the purpose and prerequisites, then proceeds logically through parameters and behavior. Each sentence adds value, though it 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?
For a 10-parameter creation tool with no output schema, the description covers purpose, prerequisites, parameters, behaviors (dry-run, uniqueness), and distinctions from related tools. It lacks explicit mention of the return value on success, but overall it's highly informative.
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 100%, but the description adds significant meaning: explains label uniqueness logic, enumerates view modes explicitly, describes optional config fields (visibleFields, filters, sort, groupBy), and the filterOperator enum. This goes beyond the 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 starts with 'Create a view (report) in an application,' providing a specific verb and resource. It explicitly distinguishes from forms and dashboards by mentioning alternatives, making the purpose clear 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Prerequisites are explicitly stated ('requires readwrite/admin mode AND SMARTSUITE_ENABLE_SCHEMA_WRITE=true'). The description explains the uniqueness check for labels and the dry-run confirmation flow. It also directs users to smartsuite_create_form for forms and notes that dashboards are separate.
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?
Annotations already indicate no read-only hint, but the description adds critical behavioral details: required permissions, destructive nature, inability to undo, and preview behavior when confirm is false. This provides transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no unnecessary words. Key information is front-loaded: the primary action comes first, followed by requirements, special cases, and warnings. 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 simplicity of the tool and lack of output schema, the description covers prerequisites, parameter behavior, destructive nature, and constraints (refusing non-dashboards). It is sufficient for an agent to understand when and how 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?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that confirm=true triggers permanent deletion while confirm=false returns a preview, and that dashboardId must refer to a dashboard report. This clarifies behavior 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: 'Delete a dashboard and all its widgets.' It distinguishes from sibling tools by mentioning it refuses non-dashboard reports, and its focus on dashboards sets it apart from other delete tools (e.g., delete_records, delete_view).
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?
Explicit prerequisites are given (readwrite/admin mode, environment variables). The description explains the confirm parameter behavior and warns that the action is destructive and irreversible. It also notes that non-dashboard reports are refused, offering implicit guidance on valid inputs. However, it does not directly compare to sibling delete tools.
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?
Annotations declare readOnlyHint=true, and the description adds value by detailing the returned data (tabs, footer, etc.) and the behavioral impact of includeWidgets (triggering extra API calls per tab). No contradictions; the description enhances transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core purpose, second expands on includeWidgets with widget types and cost. Every sentence adds value, no redundancy, and critical info 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 no output schema, the description adequately explains the return value (tabs, footer/branding, etc.) and widget details. It covers the complexity of dashboard configuration and even notes API call implications. No missing elements for a read tool with annotations.
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 100%, so baseline is 3. The description adds extra meaning by listing widget types for includeWidgets and explaining its behavior, improving upon the schema's brief text. The other parameters (IDs) are well-documented in the schema, so no further addition needed.
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 'Get the full configuration for a single SmartSuite dashboard' with a specific verb and resource. It lists the components (tabs, footer/branding, style, sharing settings) and distinguishes from siblings like smartsuite_list_dashboards (list vs. single) and create/update 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 implies usage when needing a dashboard's full configuration and mentions the includeWidgets parameter's API cost, but does not explicitly state when not to use it or directly reference alternatives like list_dashboards. It provides clear context but lacks exclusions.
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?
Annotations declare readOnlyHint=true, and the description adds context about the default slim list, the inferred isDefault field, and the optional config return, making behavior fully 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?
A single paragraph that is front-loaded with the main purpose, concise, and free of fluff. Every sentence earns its place.
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 (2 params, no output schema), the description covers purpose, behavior, default fields, optional config, and refers to the sibling tool for dashboards. No 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?
The input schema has 100% coverage, so the description doesn't need to explain parameters, but it adds value by detailing what the default output contains and what includeConfig:true returns.
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 views for a SmartSuite application, enumerates view types (grid, kanban, etc.), and explicitly excludes dashboards, distinguishing it from smartsuite_list_dashboards.
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 says to use smartsuite_list_dashboards for dashboards and explains the default vs. config options, but does not mention alternatives like smartsuite_describe_view for a single view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, indicating mutation. The description goes beyond by detailing the need for specific access modes and configuration flags, and it discloses the preview behavior when confirm is not true. No contradictions with annotations. It adds significant behavioral context that annotations alone do not cover.
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 two sentences long, each packed with essential information. The first sentence states purpose and prerequisites, the second explains behavior and data sources. Every word earns its place; no fluff or repetition.
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 simple parameters, no output schema, and minimal annotations, the description covers prerequisites, behavior, and parameter semantic. It doesn't describe the preview response format, but for a tool with a clear dual behavior, this is a minor gap. Overall, 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, but the description adds crucial semantics: it explains that confirm controls preview vs actual restore, and it tells users where to find record IDs (delete response, audit log, list_deleted_records). This goes well beyond the schema's minimal parameter 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 starts with a clear verb+resource: 'Restore soft-deleted records from the trash.' It distinguishes this tool from siblings like smartsuite_delete_records and smartsuite_list_deleted_records by specifying it's for restoration from trash, and it mentions prerequisites that separate it from other record operations.
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 states when to use the tool (restore soft-deleted records) and provides critical context: it requires readwrite/admin mode and the SMARTSUITE_ENABLE_RESTORE=true flag. It also explains the dual behavior of the confirm parameter (preview vs actual restore) and where to obtain record IDs, giving comprehensive usage guidance.
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?
The description discloses behavioral traits beyond the annotations: it is not read-only (readOnlyHint=false) and explains that it fetches the current definition, selectively updates fields, validates the expression, and supports a dry-run mode via the confirm parameter. This provides full behavioral transparency, complementing the annotations effectively.
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?
Two well-structured sentences cover purpose, prerequisites, and behavior without any fluff. The information is front-loaded and every sentence adds value. Highly concise and effective.
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 (6 parameters, no output schema), the description covers prerequisites, update mechanism, validation, and dry-run mode. It is complete for an AI agent to understand the operation and its nuances, and it differentiates well from siblings like smartsuite_update_field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters interact (only supplied fields changed) and the role of confirm (validate vs apply). This goes beyond the schema descriptions, hence a 4.
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 (update) and the resource (existing formula field), specifying that it can update expression, label, and return type. This distinguishes it from sibling tools like smartsuite_create_formula_field (create new) and smartsuite_update_field (generic field update). The verb 'update' with a specific resource provides excellent purpose clarity.
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 (readwrite/admin mode AND SMARTSUITE_ENABLE_SCHEMA_WRITE=true) and explains the behavior (fetches current definition, only supplied fields changed, validates expression, dry-run with confirm). While it doesn't explicitly state alternatives or when not to use, the context is clear enough for an AI agent to decide usage.
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?
Adds significant detail beyond the readOnlyHint annotation: describes return format (valid, safe, warnings or error), error handling, and field reference syntax. No contradiction with annotations.
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?
Two well-structured sentences. First sentence states purpose and safety. Second explains output and syntax. 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?
No output schema, but description adequately explains return types and error messages. Covers field reference syntax, safety, and typical use case. Complete for a validation 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 100%, so baseline is 3. The description adds usage context for formula syntax and returnType optionality, going beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'validate' and the resource 'SmartSuite formula expression', and explicitly notes it is safe and non-writing. This distinguishes it from sibling tools like smartsuite_analyze_formulas or field creation 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?
Explicitly says to use before creating or updating a field, and emphasizes safety. However, it does not mention when not to use or list alternatives, though the sibling context is broad.
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?
Discloses key behavioral traits: write operation (contradicts readOnlyHint: false but that's consistent), dry-run default unless confirm:true, cross-tab removal behavior, and positioning logic. No contradictions with annotations.
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?
Compact, well-structured description with no redundancies. Each sentence adds value: purpose, usage, parameter details, and edge cases are covered efficiently.
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 6 parameters, no output schema, and no enums, the description covers all essential aspects: permissions, operation modes, parameter dependencies, and preview/confirm behavior. Leaves no major 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?
Adds significant meaning beyond the schema: explains afterField semantics (field slug or section__ slug), toTab for cross-tab moves, tabId conditional requirement, and confirm flag role. Enhances understanding despite high schema coverage.
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 uses a specific verb ('Move/arrange') and resource ('field in the record-view layout'), and clearly distinguishes it from sibling layout tools by focusing on field positioning rather than section/tab management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool, including permissions required and parameter guidance for cross-tab vs within-layout moves. Does not explicitly contrast with alternative tools, but the intent is well understood.
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?
Annotations indicate write operation (readOnlyHint=false). Description adds critical behavioral details: dry-run mode unless confirm:true, reflow behavior (keeps side-by-side, stacks rows), default normalization only height. Comprehensive disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient. Front-loaded with main purpose, then prerequisites, use cases, and per-parameter details. Every sentence adds value; no 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?
For a 6-parameter tool with no output schema, description covers both modes (size and reflow), dry-run behavior, prerequisites, and parameter nuances. Complete enough for an agent to invoke 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?
100% schema coverage, and description adds substantial context: dimension 'both' also fixes width, confirm toggles apply vs dry-run, widgetTypes limited to resize only. Each parameter's meaning is enriched well beyond 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?
Description specifies verb 'repair' with resource 'dashboard widgets' and clearly distinguishes two operations (size normalization and reflow). It differentiates from sibling tools like add/update/remove widget by addressing specific dashboard anomalies.
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 states required mode (readwrite/admin) and environment variable (SMARTSUITE_ENABLE_SCHEMA_WRITE=true). Describes when to use: for wrong sizes or overlapping widgets, noting that UI re-saving doesn't fix. Lacks explicit alternatives but context is clear.
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?
Annotations only provide readOnlyHint=false, indicating a write operation. The description adds extensive behavioral details: markdown conversion, clearing help text, display format options, that the full field definition is rewritten, async application, and dry-run preview. 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 a single paragraph of 5 sentences, each providing essential information without redundancy. It front-loads the core purpose and adds concrete details efficiently.
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 output schema, the description fully covers the tool's behavior, prerequisites, and effects. No missing context for proper 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?
Schema coverage is 100%, but the description adds significant value beyond parameter descriptions: explains markdown syntax for helpText, the effect of empty string, the meaning of displayFormat values, and the confirm parameter's role in dry-run vs apply.
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: 'Set or modify a field's help text (any field type).' This is a specific verb+resource combination, and the sibling tools like smartsuite_set_field_visibility and smartsuite_update_field handle different aspects, providing distinction.
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 mentions required conditions ('Requires readwrite/admin mode AND SMARTSUITE_ENABLE_SCHEMA_WRITE=true') and explains the dry-run behavior with confirm. While it doesn't explicitly contrast with siblings, the context is clear enough for appropriate use.
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?
Discloses PATCH semantics, shallow merge, wholesale replacement of choices, async application, dry-run mode, and aiPrompt behavior. Annotations only indicate it's not read-only; description adds extensive detail.
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?
Though lengthy, every sentence carries essential information for a complex operation. Front-loaded with core purpose, but could be slightly more terse without losing clarity.
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?
Covers all aspects: prerequisites, parameter behaviors, usage patterns, alternatives, and async/dry-run details. Adequate given no output schema and moderate 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?
Schema coverage is 100% but description adds meaningful explanation of params (shallow-merged, choices replaced wholesale) and aiPrompt (preserves existing settings), going beyond basic 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 explicitly states it updates a field's label and/or params, distinguishing it from related tools like smartsuite_set_field_help_text and smartsuite_update_formula_field.
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 (readwrite/admin mode, SMARTSUITE_ENABLE_SCHEMA_WRITE=true), recommends reading the field first, and lists alternatives for help text and formula updates.
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?
Annotations only have readOnlyHint: false, so the description carries the full burden. It clearly indicates this is a write operation, explains the replace behavior for each configuration window, and states validation of field slugs. It also mentions the environment variable requirement. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a few sentences but each adds value. It is front-loaded with the main purpose and then covers requirements, behavior, and exclusions. Could be slightly more concise but is well-structured and efficient.
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 8 parameters, only one required, no output schema, and nested objects set to false, the description covers when to use, prerequisites, partial update behavior, validation, and what the tool does not handle. It also guides the agent to use other tools for viewId discovery. This is comprehensive for a complex update 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 100%, so baseline is 3. The description adds useful context beyond schema: it explains that passing sort replaces the sort rules entirely, and that filterOperator defaults to 'and'. It also mentions field slugs are validated, which is not in 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 updates a view/report, listing specific configurable attributes (label, description, visibleFields, filters, sort, groupBy). It distinguishes from siblings by explicitly stating it refuses forms/dashboards and directs to their own tools, which is a strong differentiator.
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 explicit prerequisites (readwrite/admin mode + SMARTSUITE_ENABLE_SCHEMA_WRITE=true), explains partial update semantics ('Only the parts you pass are changed'), and suggests using other tools to gather viewId and current settings. It also notes that field slugs are validated and that forms/dashboards are handled by separate tools.
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?
Beyond annotations (readOnlyHint=false), the description reveals destructive nature ('cannot be undone'), the two-step deletion process (preview vs. permanent), and special refusal cases. No contradiction with annotations.
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 a single paragraph but is concise and well-structured. Every sentence adds necessary information, with prerequisites front-loaded and 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 tool's simplicity (2 params, no output schema), the description covers all essential aspects: action, prerequisites, limitations, behavior, and destructive nature. It is complete for its 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?
Schema coverage is 100% with descriptions for both parameters. The description adds value for confirm by explaining its dry-run vs. permanent behavior, going beyond the schema description. For viewId, it restates 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 'Delete a view (report)', using a specific verb and resource. It also distinguishes from siblings by noting that forms and dashboards have their own tools.
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?
Explicit prerequisites are given (readwrite/admin mode, SMARTSUITE_ENABLE_SCHEMA_WRITE=true, SMARTSUITE_ENABLE_DELETE=true). It explains when not to use (refuses last view, forms/dashboards) and provides alternatives. The confirm parameter behavior is also clearly described.
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?
Beyond readOnlyHint annotation, description details token cost (~1k+ tokens), schema stability within session, and caching advice. No contradiction with annotations.
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?
Two paragraphs, front-loaded with key purpose. Every sentence adds value—token cost, caching, verbosity levels, and usage guidance—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?
Despite no output schema, description covers return values, token cost, caching, parameter options, and usage context. Completely adequate for a read-only schema introspection tool with 5 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaningful context for parameters, e.g., explaining includeLayout returns 'sections with collapse flags' and forceRefresh is 'only needed after schema changed'. Justifies higher score.
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?
Specific verb 'Describe' with clear resource: 'SmartSuite application schema, including field slugs, types, and options, plus the record term.' Distinguishes from siblings like smartsuite_list_fields (lighter) and smartsuite_describe_field (per-field).
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 'Always call this before creating or updating records' and provides alternatives: 'use verbosity:"compact" or the lighter smartsuite_list_fields'. Also advises caching: 'call this once per table and reuse'.
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?
Despite `readOnlyHint` annotation, description adds significant context: it is a read-only inspection tool, not meant for editing, and details the return structure for triggers vs actions, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but efficiently organized, front-loading the core purpose. Each sentence adds value, though slightly longer than minimal.
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?
Despite no output schema, the description explains return fields for both trigger and action, covers all parameters, and warns about limitations, making it fully informative for the tool's complexity.
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 100% schema coverage, the description adds meaning by explaining default values (step defaults to trigger, actionIndex defaults to 0) and the alternative actionInstanceId selection, clarifying usage 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?
Description clearly states it resolves the full schema of one automation step (trigger or action), distinguishing it from the sibling tool `smartsuite_describe_automation` which describes the whole automation.
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 advises to use `smartsuite_describe_automation` first to get the action list, then choose by index or instance ID. Also warns against using the output directly to update actions, providing clear when-to-use and when-not-to-use guidance.
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?
Annotations only set readOnlyHint=false, so the description carries the burden. It discloses that the tool writes the prompt, leaves the rest intact, builds rich-text from plain text, resolves field references, and dry-runs by default. Auth and environment requirements are noted. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph of about 100 words. It is front-loaded with the main action and contains no fluff, but could benefit from slight structuring (e.g., bullet points or separate sentences for prerequisites). Still very concise.
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 6 parameters, no output schema, and no annotations beyond readOnlyHint, the description thoroughly explains the mechanism, edge cases, and safe usage (dry-run preview). It mentions the underlying GetAutomation call for reliability. The agent has enough to use 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 100%, but the description adds vital context: promptTemplate format with {{field_slug}} syntax, applicationId as the resolution table, actionInstanceId for multi-action scenarios, and confirm's dry-run behavior. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set the dynamic prompt on an automation's AI action.' It specifies the exact resource and distinguishes itself by calling itself 'the reliable way' compared to hand-building.
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?
Explicit prerequisites are given (readwrite/admin mode, SMARTSUITE_ENABLE_SCHEMA_WRITE=true), usage instructions for dry-run vs confirmation with confirm:true, and handling multiple AI actions via actionInstanceId. It also warns against hand-building the prompt.
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?
The description adds behavioral context beyond annotations: it's a mutation requiring specific permissions, and it performs a dry-run preview unless confirm:true. This fully informs the agent about the tool's effects.
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 two sentences plus a parenthetical note. Every sentence adds essential information 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?
For a mutation tool with 4 parameters and no output schema, the description covers everything needed: purpose, parameters, prerequisites, behavior, and sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the tool's purpose (rename table and record term) and the confirm parameter's role (preview vs. apply), which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates table attributes like name and record term. It explicitly distinguishes itself as the table rename tool vs. smartsuite_update_field for field renames, providing a specific verb and resource.
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 explains when to use the tool (rename table/change record term), mentions required permissions (readwrite/admin + SMARTSUITE_ENABLE_SCHEMA_WRITE), and indicates dry-run behavior unless confirm:true. It also points to an alternative for field renames.
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?
Annotations only set readOnlyHint=false, so the description carries the burden. It details the fetch-then-apply pattern, the wholesale replacement of trigger/actions, the preservation of unprovided fields, and the engine-computed enabled state. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: purpose first, then requirements, then behavior, then warnings. Every sentence is justified given the complexity and potential for destructive updates. A minor trim could be made, but the length is warranted for safety.
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 output schema, the description explains the outcome (disabled status if invalid) and mentions statusReason. It covers prerequisites, parameter interactions, and common pitfalls. For a tool with 9 parameters and nested objects, this is thorough and 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 coverage is 100%, but the description adds crucial meaning: explains the fetch-and-apply behavior, mutual exclusivity of actions/actionGroups, the role of credentialId, and the replacement semantics for trigger and actions. This goes well beyond the 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 opens with 'Update an existing automation.' This is a specific verb+resource, clearly distinguishing from create, delete, or describe siblings. It immediately identifies the tool's core 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 states prerequisites (readwrite/admin mode, environment variable), explains how to use parameters to avoid overwriting (OMIT trigger/actions to preserve them), warns against using describe_automation_step output, and clarifies the enabled state behavior. Provides comprehensive when-to and when-not-to guidance.
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?
The description discloses behavioral traits beyond annotations: mutation (consistent with readOnlyHint=false), required mode and env variable, dry-run preview, and need for explicit confirmation. No contradictions with annotations.
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 (two sentences) and front-loaded with the main action and essential requirements. 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, no output schema), the description covers all critical aspects: purpose, prerequisites, input sources, and default behavior. It is complete for agent selection and 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?
Even though schema coverage is 100%, the description adds meaning by explaining the slug's origin (from smartsuite_list_deleted_fields) and the confirm parameter's default behavior. This enriches the schema's 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 ('Restore a soft-deleted field back into its application'), specifying the verb 'Restore' and the resource ('soft-deleted field'). It distinguishes itself from sibling tools like 'smartsuite_list_deleted_fields' and 'smartsuite_delete_field' by focusing on restoration.
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 states requirements ('readwrite/admin mode AND SMARTSUITE_ENABLE_SCHEMA_WRITE=true'), provides context on inputs ('Supply the applicationId the field belonged to and its slug (from smartsuite_list_deleted_fields)'), and explains behavior ('Dry-run preview unless confirm:true'). 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.

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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SmartSuiteFoundry/smartsuite-mcp-server'

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