Dashform MCP Server

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

Beyond annotations (readOnlyHint=false), the description discloses important side effects: creating a dashboard-visible submission record and triggering external integrations (CRM, email, webhooks). This contextualizes the openWorldHint annotation. It does not address idempotency or error handling, but covers primary behavioral traits well.

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 with zero redundancy. It front-loads the core purpose, immediately follows with critical parameter guidance, then side effects, then legacy compatibility. Every sentence earns its place with high information density.

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 7-parameter tool with nested objects and no output schema, the description successfully covers the complex input patterns (answers vs. lead), workflow dependencies, and system side effects. Minor gap: it does not specify the return value or whether the appointment is immediately confirmed versus requested pending approval.

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 57% schema coverage, the description adds crucial semantic context for the 'answers' parameter (linking it to get_form_questions output) and clarifies the 'lead' parameter as deprecated. It compensates for undocumented parameters like fit_score and service_name by explaining the primary input patterns.

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 specific verbs ('Submit', 'request') and identifies the resource (appointment/lead information). It clearly distinguishes from sibling retrieval tools like get_form_questions or get_availability by emphasizing the submission/creative nature of the operation.

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 establishes a clear workflow prerequisite by referencing get_form_questions for the answers parameter structure. It also distinguishes between the modern 'answers' approach and the deprecated 'lead' object. However, it lacks explicit 'when-not-to-use' guidance versus alternatives like check_fit.

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 (safe evaluation), and the description is consistent with this. Crucially, since no output schema exists, the description discloses the complete return structure including score range (0-100), fit assessment, confidence level, reasoning, and recommended actions—essential 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?

Four dense sentences with zero waste: purpose statement, input requirements/prerequisites, return value specification, and backwards compatibility note. Information is perfectly front-loaded and 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?

Fully compensates for the absence of an output schema by exhaustively listing return values. Establishes critical workflow context by linking to get_form_questions. Given the annotations and parameter schema quality, the description provides complete contextual coverage for tool invocation.

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 schema coverage is 100% (baseline 3), the description adds vital semantic context: 'answers' must be keyed by question keys from get_form_questions (external dependency), and 'lead' is explicitly marked as deprecated legacy. This provides necessary usage context beyond the schema definitions.

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 specific action ('Evaluate lead fit') and target resource ('against this business'). Distinguishes from siblings like book_appointment or create_form by referencing get_form_questions, positioning it as a qualification/analysis tool rather than an action or management tool.

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 references sibling tool get_form_questions as a prerequisite for obtaining question keys. Clarifies the mutual exclusivity between 'answers' (preferred) and 'lead' (legacy) parameters. Does not explicitly state when to use this versus book_appointment or form 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 correctly indicate this is a write operation (readOnlyHint: false) and not idempotent. However, the description adds no behavioral context about validation rules, what constitutes a successful creation, side effects, or whether partial configurations are accepted.

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 appropriately brief and front-loaded with the action verb, but 'full configuration support' is filler that consumes space without conveying useful information. The extreme brevity becomes a liability given 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?

Given the complex 16-parameter schema with deeply nested objects (themes, backgrounds, branching questions), the single-sentence description is inadequate. With no output schema provided, the description should have indicated what the tool returns or the complexity of the configuration options available.

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, the baseline is 3. The description adds no parameter-specific guidance (e.g., highlighting required fields like organizationId/userId or explaining the complex 'endings'/'questions' structures), but the schema sufficiently documents parameters without description assistance.

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 the basic action (create a new form) but uses vague language ('full configuration support') without specifying what configuration means. It fails to mention the two distinct funnel types (Logic vs AI) evident in the schema's 'type' enum, missing a key opportunity to clarify 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?

No guidance provided on when to use this versus siblings like 'update_form' or 'get_form'. No mention of prerequisites (organizationId/userId requirements) or that this creates a new resource rather than modifying existing ones.

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=false and destructiveHint=false, establishing this is a safe write operation. The description adds minimal behavioral context beyond the annotations—it doesn't disclose whether the reply triggers notifications, if it's stored permanently, or idempotency behavior (though annotations cover idempotentHint=false). 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 7-word sentence. While not verbose, it is too minimal to be informative—every sentence should earn its place, but this merely restates the title without adding actionable context. Appropriate brevity requires sufficient information density.

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 6 parameters including nested objects (data) and respondent metadata, the description is inadequate. It misses the opportunity to explain the respondent-centric nature of the tool (name, email, emotion fields) and provides no indication of output behavior or side effects, leaving significant gaps despite the parameter richness.

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 mentions 'form' which aligns with the formId parameter, but adds no syntax details, examples, or clarification about the nested 'data' object structure or the enum values for 'respondentEmotion'. It relies entirely on the schema for parameter meaning.

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

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

The description states the basic action ('Create') and domain ('form'), but remains tautological (restating the tool name 'create_reply'). It fails to distinguish what a 'reply' represents in this context—a form submission/response by a respondent—despite parameters like 'respondentEmotion' and 'respondentName' indicating a human submission flow distinct from form management siblings like 'create_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?

No guidance provided on when to use this tool versus alternatives (e.g., when to create a reply vs. retrieving form questions via 'get_form_questions'). No prerequisites mentioned (e.g., that the form must exist), nor exclusion criteria for 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?

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds valuable behavioral context by specifying that associated data including 'versions, replies, etc.' are also destroyed, clarifying the cascade scope beyond what the structured 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 single 10-word sentence is perfectly front-loaded, with 'permanently' conveying irreversibility and the parenthetical clarifying deletion scope without redundancy. 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 destructive operation with two parameters and no output schema, the description adequately covers the critical safety aspects (permanence, data destruction) that annotations don't specify. Could improve by mentioning permission requirements, but sufficient for tool selection.

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, the schema fully documents both 'id' and 'organizationId' parameters. The description provides no additional parameter syntax or format details, meeting the baseline expectation when structured documentation is complete.

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 ('delete') with explicit resource ('form') and scope ('all its associated data'), clearly distinguishing this from sibling tools like update_form or get_form by emphasizing the permanent and comprehensive nature of the deletion.

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 word 'permanently' implies this is for irreversible removal rather than updates or soft deletes, but there are no explicit when-to-use instructions, prerequisites (e.g., ownership requirements), or named alternatives like 'use update_form to deactivate instead.'

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?

Adds valuable behavioral context beyond annotations by disclosing the conditional return types (external link like Calendly or text message) and the dependency on configuration status. Annotations cover read-only safety; description covers output semantics.

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, zero waste. First sentence establishes purpose; second sentence explains return behavior. Every word earns its place 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?

Appropriate for a simple read-only tool with one parameter. Compensates for missing output schema by describing the two possible response formats (link vs. message). Could marginally improve by noting the external service implication of openWorldHint, but sufficient as-is.

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

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

Schema has 100% description coverage for the single 'funnel_id' parameter. The description adds no parameter-specific details, but with full schema coverage, no additional compensation is required. Baseline score 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?

States specific verb ('Get') and resource ('booking availability'). Clearly distinguishes from sibling 'book_appointment' by specifying it returns booking links/messages rather than performing actual bookings.

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

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

Provides clear context for when to use by describing the dual return behavior (booking link vs. scheduling message), implicitly guiding against using this for actual bookings. Lacks explicit naming of 'book_appointment' as the alternative for that use case.

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 openWorldHint=true, covering safety and scope. The description adds valuable behavioral context by listing the specific data fields returned (description, industry, location, services, booking link), compensating for the lack of an output schema and helping the agent anticipate the response structure.

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 zero waste: the first establishes purpose and return values, the second provides usage guidelines. Information is front-loaded and every clause earns its place. No redundancy with title or annotations.

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 single-parameter lookup tool, the description adequately compensates for the missing output schema by enumerating return fields. It appropriately leverages the readOnlyHint annotation and provides workflow context. Could be improved by mentioning error cases (e.g., invalid funnel_id), but sufficient for agent operation.

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 funnel_id parameter ('The funnel public ID or internal ID'), the schema carries the primary semantic load. The description references 'Dashform funnel' which reinforces the parameter context, but does not add significant semantic detail beyond the schema's explanation.

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 ('Get') with a clear resource ('business information for a Dashform funnel') and enumerates the exact fields returned (description, industry, location, services, booking link). It effectively distinguishes this from siblings like get_services or get_user_info by specifying 'business information' 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?

Explicitly states when to use the tool ('to understand what a business offers') and establishes a clear workflow sequence ('before checking lead fit'), directly referencing the sibling tool check_fit. This provides clear temporal and logical guidance for agent decision-making.

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 establish this is read-only and non-destructive. The description adds value by disclosing what content is returned (questions, theme, configuration), but omits error behavior, caching, or permission requirements.

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, nine words, front-loaded with the action. No redundant phrases. Efficiently conveys the retrieval scope without verbosity.

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?

Adequate for a simple 2-parameter read operation with complete annotations. The description compensates for the missing output schema by listing the key data fields returned (questions, theme, configuration).

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, the schema fully documents both 'id' and 'organizationId'. The description adds no parameter-specific guidance, meeting the baseline for high-coverage schemas.

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 clear verb ('Get') and resource ('form'), and specifies the scope with 'full details including questions, theme, and configuration'. It implies comprehensiveness versus siblings like get_form_questions, though it doesn't explicitly differentiate them.

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 versus alternatives like list_forms (to discover forms), get_form_questions (subset retrieval), or update_form. No prerequisites or conditions 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 cover readOnly/destructive hints. Description adds valuable return value disclosure ('Returns question keys, types, descriptions, and options') which compensates for missing output_schema, and adds workflow context. Does not explain openWorldHint or idempotency details.

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 high-density sentences with zero waste. First sentence covers action and return payload; second covers workflow sequencing. Well front-loaded and appropriately sized for tool 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 single-parameter read operation, description is complete. Compensates for missing output_schema by detailing return structure. Workflow integration with sibling tools is clearly specified. Annotations cover safety profile.

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

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

Schema has 100% description coverage for the single 'funnel_id' parameter. Description implicitly references the funnel context ('for this funnel') but adds no explicit parameter guidance, syntax, or examples beyond the schema. Baseline 3 appropriate when schema carries full load.

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?

Clear verb ('Get') + specific resource ('questions for this funnel'). Distinguishes from siblings by positioning it as a prerequisite data-gathering step rather than an action tool like book_appointment or check_fit.

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 sequencing instruction ('Call this BEFORE check_fit or book_appointment') with specific sibling names. Explains the purpose ('to understand what information to collect from leads'), providing clear when-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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe. The description adds valuable context that services belong to a specific business funnel, but doesn't disclose pagination behavior, rate limits, or cache semantics.

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 well-structured sentences with no filler. The first sentence establishes the primary operation (list services), and the second clarifies the optional filtering capability. Information is front-loaded and every word earns its 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?

For a simple 2-parameter read operation with good safety annotations, the description is minimally adequate. However, given the presence of 'search_services' as a sibling, it should explicitly clarify the distinction (funnel-scoped retrieval vs. search) to be 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?

With 100% schema description coverage, the schema already fully documents both funnel_id and category. The description mentions 'Optionally filter by category' which restates the schema, but adds no additional semantics, examples, or format constraints beyond the structured definitions.

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 core action (getting a list of services/products) and the scope (offered by a business through this funnel). It implicitly distinguishes from sibling 'search_services' by emphasizing the funnel-specific context, though it doesn't explicitly contrast the two 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 mentions the optional category filter but provides no guidance on when to use this tool versus the sibling 'search_services' or 'get_business_info'. No prerequisites or exclusion criteria are stated.

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?

While annotations declare the operation is read-only, the description adds valuable behavioral context about authentication methods (OAuth vs. session-based) that is not present in the structured metadata. This helps the agent understand when the parameter is required.

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 consists of two highly efficient sentences. The first states the purpose, the second provides essential auth guidance. There is no redundant or wasted text; every clause earns its 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?

For a simple read-only tool with one optional parameter and no output schema, the description is adequately complete. It compensates for the missing output schema by explicitly stating what data is returned (user ID and organization ID).

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 baseline is 3. The description adds significant semantic value by explaining the conditional logic for the sessionToken parameter (auth-method dependent), which goes beyond the schema's static 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 states a specific verb ('Get') and specific resources ('user ID and organization ID'), making the purpose clear. However, it does not explicitly distinguish from sibling tools like 'get_business_info' or 'list_organizations', which would earn a 5.

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 conditional guidance on when parameters are needed ('When connected via OAuth, no parameters are needed. For session-based auth, provide the sessionToken'). However, it lacks explicit comparisons to alternative tools or exclusion criteria.

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 read-only safety (readOnlyHint: true). Description adds valuable behavioral context about response content (includes 'merchant counts') and domain specificity ('Dashform marketplace'), though it omits pagination or caching details if applicable.

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 well-structured sentences with zero redundancy: first declares functionality and data returned, second provides usage timing. Front-loaded and appropriately sized for a simple parameterless 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?

Adequately covers the tool's simple purpose and return structure given zero parameters and no output schema. Explains what data comes back (categories with counts), though it could optionally note that results may vary (consistent with openWorldHint).

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

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

Input schema contains zero parameters, establishing baseline 4 per rubric. Description correctly avoids parameter discussion since none exist, and implies no filtering is available via 'List all'.

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 'List' with resource 'service categories on the Dashform marketplace' and scope 'all available...with merchant counts'. Clearly distinguishes from sibling search tools by focusing on category discovery rather than service search or booking.

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

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

Provides clear usage context ('Use this to understand what types of services are available before searching'), establishing it as a discovery step prior to search operations. Lacks explicit 'when not to use' or named alternative tools like search_services.

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 and destructiveHint=false. The description adds valuable behavioral context by specifying the return payload includes 'status and reply counts,' which helps the agent understand what data to expect beyond the annotation hints.

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 with zero waste. It front-loads the action ('List all forms'), specifies the required context ('of an organization'), and adds value with the return data specification ('with status and reply counts'). Every clause earns its 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 (1 parameter, no nested objects) and presence of annotations, the description is appropriately complete. It compensates for the missing output schema by mentioning 'status and reply counts.' Minor gap: no mention of pagination behavior or result 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?

With 100% schema description coverage ('The ID of the organization'), the baseline is 3. The description references 'an organization' which aligns with the organizationId parameter, but adds no additional syntax, format details, or examples 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 provides a specific verb ('List'), clear resource ('forms'), and scope ('all forms of an organization'). It distinguishes from siblings like 'get_form' (singular) and mutation tools ('create_form', 'delete_form', 'update_form') by emphasizing the plural 'all forms' and read-only nature.

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

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

The description implies usage by specifying 'all forms' (suggesting use when multiple forms are needed), but lacks explicit guidance on when to use this versus 'get_form' for single-form retrieval or filtering limitations. No explicit alternatives or exclusions are named.

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 establish this as read-only and non-destructive. The description adds scope context by specifying 'all' organizations, implying no pagination or filtering occurs, but does not address return format, rate limits, or authorization requirements beyond the structured data.

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, efficient sentence with no redundant words. It front-loads the verb and resource, delivering maximum information density without waste.

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 low complexity (single parameter), full schema coverage, and comprehensive annotations, the description is adequate for a simple read operation despite lacking an output schema. It appropriately delegates parameter details to the schema while conveying the core operation intent.

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, the baseline is 3. The description implies the 'user' parameter through the phrase 'the user belongs to', adding minor semantic context about the membership relationship, but does not elaborate on parameter format or constraints 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 (List) and resource (organizations) with specific scope ('all' and 'the user belongs to'). However, it does not explicitly differentiate from similar list operations like 'list_forms' or 'list_categories' within the description text itself, relying instead on the resource name distinction.

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 explicit guidance on when to use this tool versus alternatives, prerequisites, or conditions for use. While the input schema notes the userId comes 'from get_user_info', this dependency is not mentioned in the description field itself.

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 cover safety (readOnlyHint, destructiveHint), but the description adds crucial behavioral context about the return values—that each result includes a funnel_id. This disclosure is essential for an agent to understand how to use the output. It also clarifies the scope (Dashform marketplace). Minor gap: doesn't mention pagination behavior beyond 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?

Three sentences with zero waste: sentence 1 states purpose, sentence 2 states filtering capabilities, sentence 3 explains output utility and downstream tool relationships. Perfectly front-loaded and information-dense.

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 lacking an output schema, the description compensates effectively by identifying the key output field (funnel_id) and its relationships to four other tools. For a 4-parameter search tool with complete input schema coverage and safety annotations, this description provides sufficient context for correct invocation and result handling.

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, the baseline is appropriately 3. The description mentions the three filter dimensions ('category, location, or keyword') which map to schema parameters, but doesn't add syntax details, format constraints, or semantic nuances beyond what's already documented in the schema properties.

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 ('Search') and clearly identifies the resource ('businesses and service providers on the Dashform marketplace'). It effectively distinguishes itself from siblings like get_business_info by positioning itself as the discovery/entry point that returns funnel_ids for use with those detail-oriented 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?

Excellent workflow guidance: explicitly lists four specific sibling tools (get_business_info, get_services, check_fit, book_appointment) that consume the funnel_id output from this tool. This creates a clear usage chain. It also implicitly signals when to use this tool (initial discovery) versus the others (specific actions).

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?

Adds valuable return-value context ('funnel_id for booking') beyond annotations, which is critical given no output schema exists. Confirms open-world scope ('across all marketplace merchants') aligning with openWorldHint. Does not mention rate limits or pagination, but annotations cover safety profile.

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: sentence 1 states purpose, sentence 2 lists filter dimensions, sentence 3 provides return-value critical for downstream workflow. Information is front-loaded and dense.

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?

Appropriately complete for a 6-parameter search tool with no output schema. Compensates for missing output schema by disclosing the critical 'funnel_id' field in results. Could mention default/limit behavior or result sorting, but schema covers 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 has 100% coverage (baseline 3). Description adds semantic value by mapping 'name' to 'query' parameter and grouping 'min_price/max_price' as 'price range', helping agents understand filter intent. Omits mention of 'limit' parameter, but this is minor given 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?

Clear specific verb ('Search') + resource ('services') + scope ('across all marketplace merchants'). Distinct from sibling 'search_merchants' by focusing on services rather than merchants, and from 'get_services' by emphasizing the search/browse capability.

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 through mention of 'provider funnel_id for booking' (linking to book_appointment workflow), but lacks explicit contrast with 'get_services' or guidance on when to search vs retrieve by ID. No 'when-not-to-use' guidance 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 aligns with the idempotentHint annotation by clarifying the partial-update semantics ('Only provided fields are updated'), confirming that omitting fields preserves existing values. However, it fails to disclose other behavioral traits such as error handling (what happens if the form ID doesn't exist), rate limits, or the structure 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 consists of exactly two sentences with zero redundancy: the first establishes the operation scope and the second clarifies the partial-update behavior. Every word earns its place, and the critical behavioral constraint ('Only provided fields are updated') is front-loaded in the second sentence.

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 high schema coverage and lack of output schema, the description adequately covers the basic operation. However, for a complex tool with 16 parameters including nested objects for themes, backgrounds, and branching logic, the description remains minimal—it does not mention return values, error scenarios, or group the parameters conceptually to aid agent comprehension.

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, the input schema already fully documents all 16 parameters. The description broadly categories updatable aspects ('configuration, questions, theme') but adds no specific syntax, format details, or parameter relationships beyond what the schema provides, meeting the baseline for high-coverage schemas.

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 updates a form's 'configuration, questions, theme, and other settings' with a specific verb and resource. However, while the verb 'Update' implicitly distinguishes this from sibling tools like create_form or delete_form, it does not explicitly clarify when to choose this over alternatives or mention the core requirement of an existing form ID.

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 phrase 'Only provided fields are updated' provides crucial guidance on the partial-update (PATCH-like) behavior, helping agents avoid sending complete payloads. However, it lacks explicit when-to-use guidance (e.g., 'use this to modify existing forms, not to create new ones') and does not mention prerequisites like requiring the form to already exist.

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