Tabflows

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

Annotations already indicate destructiveHint=true, but the description adds the concrete external side effect: 'HubSpot sends them the invitation and the calendar event'. It also discloses the consent gate and the prohibition on fabricating details, which goes beyond annotation coverage.

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

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

Three sentences, each earning its place: the action, the external side effect, and the key precondition. No filler, with important constraints 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?

With a full input schema, output schema present, and annotations covering destructive/read-only behavior, the description supplies the missing operational context: when to book, what happens externally, and the consent condition. Nothing needed for correct invocation is omitted.

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%, and the schema already explains startTime as returned by get_demo_availability, durationMinutes as the matching value, and consent's exact requirement. The description mostly restates these constraints; the only novel bit, 'never invent their details', is more behavioral than parameter-specific.

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 'Book a time on the Tabflows demo calendar', naming a specific action and resource. It also ties the call to availability from get_demo_availability, distinguishing it from sibling tools like get_demo_booking_link or fetch.

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 guidance: 'Only call this after the person has chosen the time and agreed to Tabflows contacting them at that email; set consent to true only then'. This gives a clear precondition and when-not-to-call instruction, plus 'never invent their details'.

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 read-only and not open-world, and the description adds meaningful behavioral context: omitted inputs fall back to calculator page defaults, and the output is characterized as 'back-of-the-napkin math, not accounting advice.' This goes beyond the annotations without contradicting them.

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 concise sentences that front-load the core purpose, then cover defaults, outputs, and a caveat. Every sentence adds decision-relevant information, and there is no filler or 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?

The tool is read-only and has an output schema, so the return values are documented elsewhere. Still, with 10 optional parameters and zero schema descriptions, the description could more explicitly state which inputs are monthly versus annual and whether the overhead should be passed as individual line items or a total.

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 0%, so the description must carry the semantic burden. It does map the main input categories: membership fee, annual pay goal, monthly overhead, and per-member cost, and implies that overhead parameters like rent and staff are monthly. However, it does not enumerate all ten parameters or clarify units for ambiguous ones like 'other' and 'supplies.'

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's function with a specific question: 'How many members a direct primary care practice needs to break even.' It also lists inputs and outputs, making the purpose unambiguous. However, it does not explicitly distinguish itself from sibling tools like dpc_startup_cost, which is a similar financial calculator.

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 intended use case is implied by the description—break-even planning for a DPC practice—but there is no explicit 'when to use this' guidance or mention of alternatives. The default-value note is useful but does not help an agent choose between this and other calculator 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 declare readOnlyHint=true, so the description doesn't need to prove safety. It adds useful behavioral detail: the calculation formula, the 15% cushion, preset options with a default, override semantics, and the 'rough planning math' caveat. This goes beyond the structured annotations without contradicting them.

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 compact and front-loaded: it states the purpose, formula, preset behavior, override capability, and caveat in two sentences. Every clause adds useful information, with no filler or 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?

The presence of an output schema means return values don't need elaboration. The description covers the calculation approach, defaults, overrides, and rough-planning nature. The main gap is the lack of per-parameter semantics for most line items, but given the output schema and intuitive property names, the description is close to 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 0%, so the description carries the burden for parameter meaning. It explicitly explains preset values and the roles of monthlyBurn and runwayMonths, but the other nine numeric line items are only referred to generically as 'line items'. An agent gets little semantic guidance for legal, space, buildout, supplies, equipment, insurance, marketing, or softwareSetup beyond their property names.

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 computes an estimated launch budget for a direct primary care practice, including the exact formula: one-time setup costs plus runway reserve (monthly burn times runway months), then a total with a 15% cushion. It also explains preset starting points and line-item overrides, making the tool's function specific and distinguishable from siblings like dpc_break_even.

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 how to use the tool (choose a preset, override line items) but gives no guidance on when to choose this tool over alternatives such as dpc_break_even or quote_tabflows_price. There are no explicit conditions, exclusions, or references to sibling 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 mark the operation as read-only, so the description only needs to add behavior beyond that. It does so by disclosing that the result is 'full markdown,' which informs the agent about the response format and conversion behavior.

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, well-structured sentence that front-loads the main behavior and packs essential parameter context into a parenthetical. There is no redundancy or 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?

For a simple one-parameter read-only tool with an output schema and a clear identifier convention, the description covers everything needed to call it correctly. The mention of search provenance and the site-path format removes the main ambiguity.

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 provides only the parameter name and length constraints, so the description carries the full semantic burden. It clearly explains that id is a site path (e.g., /pricing) and that it comes from search results, making the parameter's meaning and expected format unambiguous.

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 identifies the resource (a tabflows.com page) and the key identifier (a site path such as /pricing). It distinguishes the operation from search by requiring an id, though it does not explicitly differentiate from the sibling get_page 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?

The description gives clear context by specifying that the id is a site path 'as returned by search,' telling the agent where valid ids come from. It does not state exclusions or compare directly with get_page, but the provenance guidance is concrete and useful.

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 and openWorldHint annotations, the description adds valuable behavior: times are UTC ISO timestamps that must be converted, the timezone affects which month is read and the booking/invitation, durationMinutes coupling is required, and availability can change between reads. This gives the agent important operational knowledge not present in 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 compact, front-loaded with the core purpose, and each sentence earns its place by covering a distinct operational concern: format, timezone behavior, booking constraints, and freshness.

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 tool is simple with an output schema and helpful annotations. The description covers all critical usage details an agent needs: timezone handling, timestamp conversion, durationMinutes pairing, booking-tool linkage, and data freshness. Nothing essential 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?

The input schema already covers both parameters with descriptions at 100% coverage, so the baseline is 3. The description adds meaning by explaining the timezone's role in month selection and its relationship to book_demo, going beyond what the schema alone communicates.

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 and resource: it gets open times on the Tabflows demo calendar, grouped by meeting length. This clearly distinguishes it from sibling tools like get_demo_booking_link, whose purpose is centered on a booking link rather than availability.

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 operational context: pass the person's IANA timezone, use the same timezone for book_demo, and only book a start time under the durationMinutes it is listed with. It does not explicitly name alternatives or exclusion cases, but for this tool the usage context is clear and actionable.

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?

Although readOnlyHint=true is annotated, the description adds meaningful behavioral context by stating 'Books nothing itself; the person completes it.' This clarifies that the tool is a pure link provider and does not perform any action on the booking, going 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 short sentences convey the full purpose and the critical caveat about not booking anything. The 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 zero-parameter, read-only tool with an output schema, the description fully covers what matters: what the links are for and what side effects do not occur. Nothing an agent needs to invoke it correctly 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?

There are zero parameters, so the schema already covers everything. The baseline of 4 applies because there is no parameter information needed and the description appropriately focuses on behavior rather than inputs.

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 precisely what the tool provides: links for a human to book a Tabflows demo or sign up. It distinguishes this from booking tools by explicitly saying it books nothing itself, making the resource and action clear.

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 makes the context clear: use this tool when the human needs a demo booking or sign-up link. It doesn't explicitly name alternatives or exclusions, but the tool's scope is so distinct from siblings that little ambiguity exists.

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 read-only safety profile is covered. The description adds useful behavioral context beyond the annotations by stating that the response contains every field the page shows and includes the canonical URL, which clarifies the exact payload an agent can expect.

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, tightly packed sentence with no filler. It front-loads the resource and key, then states the return scope. Every word contributes useful 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?

For a simple read-only lookup with one well-defined parameter, an output schema, and annotations covering safety, the description is largely complete. It explains the return contents and the singular nature of the result. It does not discuss invalid-slug behavior, but that is not essential 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 description coverage is 0%, so the description carries some burden, but there is only one parameter and the schema fully defines it with a pattern and maxLength. The description reinforces that slug is the lookup key for a single listing, but it does not add much meaning beyond what the parameter name and schema already convey.

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 identifies the resource ('One DPC Finder listing'), the lookup key ('by slug'), and the scope of the return value ('every field its page shows and its canonical URL'). This distinguishes it from the sibling search_dpc_practices tool, which would return multiple results rather than a single listing.

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 'One DPC Finder listing by slug' establishes the clear usage context: use this tool when you already have a slug and need a single practice. It does not explicitly say 'use search_dpc_practices when you do not have a slug,' but the sibling name and the contrast between singular and search make that alternative inferable.

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 openWorldHint=false, so the safety profile is covered. The description adds some context about the response shape (what Tabflows does with the tool, its features, and its page) but says nothing about not-found behavior, errors, or other edge cases.

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 front-loaded sentence: the key selection mechanism ('One integration by slug') comes first, followed by the content preview. Every word contributes, with no 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?

For a low-complexity read-only tool with one parameter and an output schema, the description is mostly sufficient: it tells the agent what to pass and what kind of data to expect. It does not address error cases, but the output schema and annotations cover much of the remaining 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 description coverage is 0%, so the description must compensate for documenting the slug parameter. It only says 'by slug,' which largely restates the parameter name and adds little beyond what the schema's pattern already implies; it does not explain how to obtain a valid slug or what the slug refers to beyond 'integration.'

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 identifies the resource as a single integration selected by slug and previews the returned content ('what Tabflows does with that tool, its features and its page'). It is clear enough to distinguish from sibling list_integrations, though it lacks an explicit verb beyond the tool name.

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 'One integration by slug' implies this is the tool to use when you already have a slug and need a single integration, as opposed to listing integrations. However, it never explicitly names an alternative or states 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 readOnlyHint=true, but the description adds that only public pages are accessible and that the result is the full markdown, which is beyond what the annotations provide. It does not cover error behavior, but that is a minor gap given 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?

A single sentence that front-loads the key purpose, then gives concrete examples. Every word contributes.

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 one-parameter read-only tool with an output schema, the description covers the input semantics with examples and the expected return content. No prerequisites, authentication, or destructive behaviors need to be disclosed.

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 provides only type/length constraints with no description (0% coverage), so the description's examples (/pricing, /faqs) and the phrase 'by path' are necessary to explain what 'path' means. For a single simple parameter, this is sufficient.

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 title and description name the exact resource (tabflows.com pages) and the operation (fetch full markdown by path). It is clearly distinguishable from sibling tools like get_integration or search, even without naming 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 makes the intended use explicit: retrieve the full markdown of any public tabflows.com page given its path. It does not explicitly state when not to use it or name alternatives, but the scope is clear enough to route the agent.

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 safe read-only nature is covered. The description adds useful context about what counts as an integration and that the category filter is optional, but it does not describe output shape, pagination, or any other runtime behavior. This is acceptable given the annotations but not rich.

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

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

The description is a single compact sentence with no filler. It front-loads the resource and then adds the filter capability. The only structural issue is that it is phrased as a noun phrase rather than a clear imperative 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 output schema exists, the description does not need to explain return values. The tool is simple, with one optional enum parameter and read-only annotations. The description covers the domain and the filter option, making it sufficiently complete for an agent to invoke correctly, though a brief note about what each integration entry contains would have been a minor improvement.

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 0%, so the description must compensate. It does convey that the category parameter is optional and filters results, and it gives examples that overlap with the enum values. However, it does not explain the exact meaning of each enum option or how the filter behaves, though the schema itself lists the allowed 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?

The title and description together clearly identify the resource (Tabflows integrations) and the action (list). The description adds helpful examples of integration types, and the resource is distinct from siblings like get_integration and list_workflows. It would be stronger with an explicit verb in the description itself, but the meaning is 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 gives no guidance on when to choose this tool over alternatives such as get_integration or search. It only mentions the optional category filter, which is parameter-level usage rather than tool-selection guidance. No exclusions or sibling comparisons are 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 and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by clarifying that it returns only documented workflows and enumerates the kind of content included (triggers, steps, outcome, time saved). It does not contradict 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 that is front-loaded with the core purpose and adds only meaningful detail about what the workflows include. There is no redundancy with the title or schema.

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 parameterless list tool with an output schema, the description is complete: it identifies the resource, the scope ('Documented'), and the content structure of the results. No prerequisites, filters, or pagination concerns are relevant.

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 tool has zero parameters, so there is nothing for the description to explain beyond what the schema shows. The description correctly focuses on the output content rather than parameter details, matching the baseline expectation for a parameterless tool.

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 ('List') and resource ('Tabflows workflows') and differentiates itself from sibling tools like list_integrations by focusing on workflows. The mention of 'Documented' further narrows the scope, making the tool's 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 the tool is used when you need to see documented workflows and their associated details, but it does not explicitly say when to use it versus alternatives. No exclusions or alternative conditions are provided, though the presence of a distinct 'list_workflows' among siblings makes the intended use reasonably inferable.

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 the description adds useful context: the price depends on two practice attributes and the response includes a breakdown and the pricing rule. This goes beyond the structured annotations without contradicting them.

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 with no redundant content. The first sentence defines what the tool computes and returns; the second provides a clear usage directive.

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 pricing calculator with an output schema, the description covers the essential inputs and the nature of the response. It does not mention caveats such as regional pricing or data freshness, but those are not clearly required given the tool's narrow scope.

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 0%, but the description names both inputs: 'number of locations and monthly paying patients,' which maps directly to locations and monthlyPayingPatients. It adds domain meaning beyond the bare parameter names, though it does not clarify units or edge-case semantics.

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 quotes the monthly Tabflows price based on locations and monthly paying patients, and that it returns a breakdown and pricing rule. It distinguishes the tool from quoting prices from memory or other pages, but it does not contrast against a specific sibling tool, so it falls just short of full differentiation.

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 second sentence gives explicit guidance: always use this tool rather than quoting prices from memory or other pages. This establishes a clear context for use, though it does not address when to use related tools such as dpc_break_even or dpc_startup_cost 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?

Annotations declare readOnlyHint=true and openWorldHint=false, so the description adds context about scope (web content) and the return value (page ids) that are not in annotations. It clarifies the output is an intermediate step for fetch, which is useful beyond structured data. Minor gap: no mention of result limits or formatting, but with annotations covering safety, this is acceptable.

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

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

Three sentences with minimal waste. The core purpose and scope are front-loaded, and the exclusion of DPC Finder is stated at the end. 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?

Complexity is low (single parameter, no nested objects). An output schema exists, so return values need not be described. The description covers what is searched and how results link to fetch, but could mention if the search is case-insensitive or supports partial matches. This is minor, so a 4 is appropriate.

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 0% description coveragehare and only one parameter 'query'. The description implies that query is a keyword string but does not add syntax details. However, baseline is 3; the description's context on scope helps the agent understand what to query, earning a 4 because it compensates for the schema gap.

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 it performs keyword search over tabflows.com page titles and summaries, enumerates content types (product, pricing, FAQs, etc.), and specifies it returns page ids to pass to fetch. This distinguishes it from search_dpc_practices and other retrieval 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?

It explicitly states the scope of indexed content and names the alternative search_dpc_practices for DPC Finder listings. This tells the agent when to use this tool vs. the sibling, leaving no ambiguity.

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 openWorldHint=false, covering the safety profile. The description adds useful behavioral detail beyond the annotations, stating that results include full listings with address, phone, and doctor 'as on file' and that match count is returned for paging. It does not discuss rate limits or auth, but for a read-only search tool the added return behavior is meaningful.

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 with no filler. It front-loads the search purpose and criteria, then succinctly states the return content and paging information. Every clause contributes directly to the agent's ability to understand and call the 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?

The description is clear on searchable fields and return format, and the output schema covers the response shape. However, it does not explain that all parameters are optional, how multiple filters combine, or how offset and limit map to paging. For a six-parameter search tool with these constraints, this is a notable gap even if an agent can infer a lot.

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 covers 50% of parameters with descriptions (city, query, state). The description adds meaning for the model parameter by naming it 'practice model' and reinforces query matching against name, city, doctor, and specialty. However, limit and offset are only implied by 'paging' and are not explicitly described; at 50% schema coverage the description partially compensates but leaves gaps in parameter understanding.

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 identifies the resource ('Tabflows' DPC Finder directory of direct primary care practices in the US') and the action (search), and enumerates search criteria. It is specific enough to distinguish from a generic search, but it does not explicitly contrast itself with siblings like 'search' or 'get_dpc_practice', so it stops short of full sibling differentiation.

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?

Usage is implied by the description: an agent can infer it is for searching the DPC directory by free text and filters. However, there is no explicit guidance on when to use this instead of 'get_dpc_practice' for a single known practice, nor any statement of when not to use it or requirements like all parameters being optional.

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