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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Beyond the minimal annotation (readOnlyHint: false), the description discloses several important behaviors: SmartSuite adds a default field set, a default Title primary field is created, recordTerm is set explicitly to avoid broken list/grid widgets, and the call is a dry-run unless confirm:true. This significantly exceeds what annotations alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but densely informative; every sentence contributes either a requirement, an alternative, a side effect, or a rationale. The core action and prerequisites are front-loaded, and the key instructions about using fields inline and the dry-run behavior are clearly emphasized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex creation tool with no output schema and sparse annotations, the description covers the essential operational details: required permissions, side effects on the table, the bulk field path, the default field set, the recordTerm risk, and the confirm gate. An agent can invoke this tool correctly without needing additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds meaningful parameter context: fields reuse the smartsuite_create_field shape, aiPrompt is unsupported at table creation, recordTerm is described with the widget-breaking pitfall, and confirm's dry-run semantics are reinforced. This goes beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: "Create a new table (application) in a solution." It clarifies that 'application' means table and distinguishes this from field-creation tools by naming smartsuite_create_field and smartsuite_create_fields as alternatives for existing tables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states requirements (readwrite/admin mode and SMARTSUITE_ENABLE_SCHEMA_WRITE=true), when to use this tool (when a table is new), and when to use alternatives (adding fields afterwards via smartsuite_create_fields). It also explains the dry-run behavior and confirm flag, leaving no ambiguity about invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations carry only readOnlyHint=false, so the description bears the full behavioral burden and discharges it thoroughly: dry-run preview unless confirm:true, SmartSuite auto-filling defaults, auto-assigned choice colors/order, auto-created backlinks, AI instructions auto-built with field-reference pills plus an explicit 'do NOT hand-build ai_agent.instructions' warning, auto-generated slug, and auto-placement in the record-view layout. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but for a tool covering 20+ field types plus an AI sub-feature, every block earns its place: purpose and requirements are front-loaded, followed by the sparse-params pattern, type-specific examples, sibling routing, the AI special case, and closing behavioral notes. Dense and logically ordered; only marginally trimable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter tool with nested objects and no output schema, the description is nearly complete on invocation and behavior, including the non-obvious dry-run default and the env-var gate. The one gap is that it never states what the tool returns on successful creation or what the dry-run preview actually shows, though slug generation is mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema's params field explicitly defers to the description ('See the tool description for which params each type needs'). The description delivers concrete per-type semantics beyond the schema: choices with value_help_text/weight, linked_application/entries_allowed, linked_field/field_selection/function, precision/separator, currency, max_length, and the aiPrompt {{field_slug}} mechanism.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Create a field of any type in an application') and immediately distinguishes scope by adding 'including rollup and lookup fields — not just formulas', then routes formula work to smartsuite_create_formula_field. An agent can tell this tool apart from its siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternative ('For formula fields use smartsuite_create_formula_field'), states hard prerequisites (readwrite/admin mode and SMARTSUITE_ENABLE_SCHEMA_WRITE=true), and gives the sparse-params rule ('Provide params only where they matter'). Also clarifies the dry-run vs confirm:true execution path, leaving no ambiguity about when this tool actually creates.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With only readOnlyHint=false in annotations, the description carries the full behavioral burden and delivers thoroughly. It discloses that all entries are validated before writes, failed fields do not abort the batch, the call performs one request per field due to API limitations, sequential execution avoids rate limits and dropped fields, and fields append to the end of the table. This is rich, non-obvious behavior that annotations alone could never convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every clause earns its place: alternative routing, prerequisites, validation guarantees, performance expectations, failure semantics, ordering behavior, and an alternative batch path. Critical operational guidance is front-loaded, and no filler or tautological phrasing is present. The density is justified by the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch mutation tool with no output schema, this description is remarkably complete. It covers when to use it, prerequisites, validation behavior, performance characteristics, failure handling, result reporting format (created:true/false plus error), positioning semantics, a faster alternative, and the dry-run behavior. An agent has everything needed to invoke it correctly and recover from partial failures.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents all parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema: it specifies the exact entry shape, references smartsuite_create_field's per-type params guide for shared semantics, clarifies that slugs are generated, and explains order significance and failure-reporting implications. This goes beyond schema repetition without needing to document every fieldType-specific option.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Create MULTIPLE fields in one call.' It immediately distinguishes itself from the sibling smartsuite_create_field by framing it as the bulk alternative, so an agent knows exactly what this tool does and how it differs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent when to use this tool instead of repeatedly calling smartsuite_create_field, and when to use smartsuite_create_application instead for table-plus-fields creation. It also provides prerequisites (readwrite/admin mode, SMARTSUITE_ENABLE_SCHEMA_WRITE=true) and the confirm:true requirement, leaving no ambiguity about invocation conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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

The description discloses several non-obvious behaviors: validation before creation, dry-run behavior without confirm, automatic slug generation, append-to-end positioning, and that SmartSuite ignores field positioning. The annotation only says readOnlyHint=false, so the description carries the full burden and exceeds it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but information-dense, with every sentence contributing a distinct behavioral fact. It is front-loaded with the core purpose, then prerequisites, then behavior, and ends with a useful pointer to a sibling tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with no output schema, the description covers prerequisites, validation, dry-run semantics, exact confirm behavior, auto slug, positioning behavior, and the relevant alternative. Nothing critical is missing 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.

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 reinforces the confirm behavior that the schema already documents and adds context about validation and auto slug, but it does not add new per-parameter semantics beyond the schema. This is adequate compensation given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Create a new formula field in a SmartSuite application.' It clearly distinguishes this from sibling tools like smartsuite_validate_formula, smartsuite_update_formula_field, and generic smartsuite_create_field by focusing on formula fields and the create action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit prerequisites (readwrite/admin mode and SMARTSUITE_ENABLE_SCHEMA_WRITE=true) and explains the confirm:true requirement for actually creating versus dry-run. It also points to smartsuite_move_layout_field for rearrangement, though it does not explicitly contrast with smartsuite_validate_formula or smartsuite_create_field.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already mark this as read-only, and the description adds useful behavioral details: the URL is temporary and the tool is disabled when an allowlist is configured. It does not mention response format or expiration duration, but the read-only annotation 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by a compact example and a necessary constraint note. Every sentence adds value, and there is no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema, the description sufficiently covers inputs, source of the handle, output nature (signed CDN download URL), and a key environment-specific limitation. An agent has enough information to use the tool correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description already identifies the handle property. The description adds meaning by showing the full file object structure and clarifying where the handle originates, which helps the agent extract it correctly from a file field value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Resolve') and resource ('SmartSuite file handle to a signed CDN download URL'), making the tool's function immediately clear. It also explains where file handles come from (filefield values), which uniquely identifies this tool among siblings like upload_file and move_attachments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly tells the agent to pass the 'handle' property from a file object, and even provides an example field value. It also warns about the allowlist configuration that disables the tool, giving practical usage context. It does not explicitly name alternative tools, but no direct alternative exists for this operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.