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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Add a recipient,' which implies a mutation but does not state whether the call is idempotent, what happens if the email already exists in the list, whether any email is triggered, or what errors might occur. This is insufficient for a write operation without annotation support.

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 with zero filler. It efficiently communicates the core action, though it is terse to the point of omitting useful detail. Still, for pure conciseness, it earns a high score.

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

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

For a tool with 5 parameters, no output schema, and no annotations, this description is far too thin. It does not explain return values, side effects, error conditions, or the meaning of optional fields, leaving an agent guessing about how to correctly invoke and interpret the 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 only 40% (descriptions for listId and emailAddress only), leaving firstName, lastName, and companyName undocumented. The description does not compensate at all—it mentions none of the parameters or their meanings, so the agent receives no help in understanding the optional fields or their formats.

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

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

The description clearly states the action ('Add') and resource ('a recipient to a Customer Thermometer recipient list'), making the tool's core purpose unambiguous. It naturally contrasts with sibling tools like customerthermometer_unsubscribe_recipient, which handle the opposite operation. However, it does not mention the optional fields (firstName, lastName, companyName) that are part of the tool's 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 is provided about when to use this tool versus alternatives like customerthermometer_unsubscribe_recipient or customerthermometer_get_recipient_lists. There are no mentioned prerequisites (e.g., list must exist), no exclusions, and no context about how this differs from other recipient operations beyond the basic 'add' verb.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'raw survey responses' and optional filters, but doesn't disclose pagination behavior, default limits, response format, or whether results are sorted. For a data retrieval tool, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Get raw survey responses') and then lists filters. Every word earns its place, though the temperature mapping could be considered redundant with the 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 filtered retrieval tool with no output schema and no annotations, the description covers the basic purpose and filter options. However, it lacks information about default behavior (e.g., default limit, date range defaults), response structure, and how it relates to sibling tools like get_comments. This is adequate but has clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds the temperature value mapping (1=gold, etc.) which is also in the schema, and clarifies blastID means 'blast/send'. This adds marginal value but doesn't go beyond the schema's existing descriptions.

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

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

The description clearly states the tool retrieves raw survey responses with optional filters, using a specific verb ('Get') and resource ('raw survey responses'). It distinguishes itself from siblings like get_comments and get_happiness_value by focusing on raw responses, though it doesn't explicitly name a sibling alternative.

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 listing optional filters (temperature, blast, date range), but it doesn't explicitly state when to use this tool versus alternatives like get_comments or get_nps_value. The context is clear for a filtered retrieval tool, but no exclusions or alternative routing 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?

With no annotations, the description must disclose behavior on its own. It identifies the operation as a read and lists optional filters, but it does not describe pagination/limit semantics, response shape, or whether filters combine. This leaves the agent without important behavioral context beyond the operation itself.

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 front-loaded sentence states the action and resource first, then the optional filters. There is no filler or redundant repetition of schema details.

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 tool with five optional parameters and no output schema or annotations, the description is minimal but covers the core purpose and filter dimensions. It doesn't explain default behavior, response format, or filter interactions, which are meaningful gaps given the absence of annotations and output schema.

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

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

All five parameters are already described in the schema (100% coverage), so the description adds no new parameter-level detail. It does summarize the filter dimensions (temperature, blast, date range), which matches parameters but doesn't exceed the schema. Baseline 3 applies.

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

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

The description names a specific verb ('Get') and resource ('free-text comments left with survey responses'), and the optional filter clause adds scope. This clearly separates it from sibling tools like get_nps_value and get_happiness_value, which target metrics rather than comments.

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 tells the agent the operation and filter options, so usage is implied, but it does not explicitly say when to choose this tool over get_blast_results or get_nps_value, nor does it mention exclusions. There are no alternative tool references, leaving selection guidance mostly to inference.

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

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

With no annotations, the description carries the full burden. 'Get' clearly indicates a read-only operation with no side effects, and 'remaining credits' describes the account state being queried. It does not mention authentication, but for a zero-parameter read-only tool this is sufficient.

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

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

A single, direct sentence states the resource, the operation, and the account scope with no filler or repetition. Everything present 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 getter with no output schema, the description is complete: it states what action is performed and what result is returned (a count of remaining credits). Nothing important 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 has zero properties, so there are no parameters needing documentation. The description's mention of 'on the account' clarifies the implicit scope. This meets the baseline for a no-parameter 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 uses a specific verb ('Get') and resource ('remaining Thermometer send credits'), making the tool's function immediately clear. It also distinguishes itself from siblings that handle thermometers, recipient lists, sending, and results.

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

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

The description implies when to use it — whenever an agent needs the account's remaining send credit count — but it gives no explicit context about when not to use it or which sibling might be an alternative. For such a simple read-only tool, the implied usage is acceptable but not explicit.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, how the percentage is calculated, what happens when filters are applied, whether results are paginated, or what the response format looks like. The description adds minimal behavioral context beyond the name.

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 concise sentence that front-loads the core purpose. It is efficient and free of filler, though it could add a brief note about filtering behavior without becoming verbose.

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

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

For a tool with no annotations, no output schema, and four optional parameters, the description is thin. It does not explain the return value structure, how the Happiness Factor is computed, or how filters affect the result. An agent would need to infer too much to call this tool correctly in varied scenarios.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds the context that these parameters filter the response set, but it does not explain how the parameters interact (e.g., whether fromDate/toDate are required together, or how blastID relates to the date range). Baseline 3 is appropriate since the schema does the heavy lifting.

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 resource ('Happiness Factor as a percentage'), and mentions the account or a filtered set of responses. It is clear enough to distinguish from siblings like get_nps_value and get_comments, though it does not explicitly name those alternatives.

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 mentioning 'account or a filtered set of responses', and the parameters (fromDate, toDate, blastID, limit) suggest filtering. However, it does not explicitly state when to use this tool versus alternatives like get_nps_value or get_blast_results, nor does it provide exclusions or prerequisites.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully states the return value is a positive or negative integer and that it applies to the account or filtered responses. However, it does not mention default date ranges, whether results are read-only, or how the filter parameters interact.

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 with no filler. It states the action, the resource, the return type, and the scope without wasting 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?

The description explains the return value and general scope, which is important since there is no output schema. It does not explain filtering semantics or default behavior, but the 100% schema coverage and simple getter nature make it minimally adequate.

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

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

Schema description coverage is 100%, so the parameters are already documented in the schema. The description adds no additional detail about parameter behavior beyond implying date and blast filtering. This meets the baseline for fully covered schemas but does not exceed it.

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

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

The description clearly identifies the operation ('Get the Net Promoter Score') and the scope ('for the account or a filtered set of responses'). It also states the return type as an integer, which helps distinguish it from related metrics like happiness value. However, it does not explicitly differentiate itself from sibling tools beyond naming the metric.

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 is provided about when to use this tool versus alternatives such as customerthermometer_get_happiness_value or customerthermometer_get_blast_results. The description implies it is for NPS retrieval, but it does not state exclusions or preferred conditions.

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

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

With no annotations, the description carries the full burden. It discloses the core behavior (listing all recipient lists with names and IDs) and implies a read-only operation, but it does not mention authentication, pagination, or response shape. This is adequate for a simple list tool but minimal.

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 that communicates the operation, resource, scope, and output fields with no wasted words. It earns its place entirely.

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 (no params, no annotations, no output schema), the description is nearly complete: it states the account scope and what is returned. The only minor gap is not specifying the return format (e.g., array of objects), but this is not critical for a list-all endpoint.

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 are no parameter semantics to clarify. Per the baseline for 0-parameter tools, a score of 4 is appropriate since the description correctly omits any parameter-related text.

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'), a clear resource ('recipient lists'), and the exact output fields ('names and IDs') on a defined scope ('the Customer Thermometer account'). This distinguishes it from siblings like customerthermometer_get_thermometers or customerthermometer_get_credits without needing to open schemas.

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: you call this when you need recipient list names and IDs. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives such as customerthermometer_add_recipient_to_list or customerthermometer_unsubscribe_recipient, leaving selection to inference.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns names and IDs, implying a read-only listing behavior, but it does not mention authorization requirements, result ordering, pagination, or what happens with empty accounts. Adequate but thin.

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, front-loaded sentence with zero filler. It states the verb, resource, scope, and return content efficiently.

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

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

For a zero-parameter listing tool with no annotations and no output schema, the description covers the essential invocation knowledge: what the tool returns and at what scope. Minor gaps exist (pagination, ordering), but nothing an agent needs to successfully invoke it.

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 the baseline is 4. The description appropriately clarifies what the returned list contains (names and IDs), which is the only semantic information an agent needs.

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'), a specific resource ('Customer Thermometer survey templates'), and the account scope, and clarifies the return content ('Thermometer names and IDs'). It is easily distinguished from siblings like get_recipient_lists, get_credits, and send_email.

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 context is implied: an agent would call this when it needs to enumerate available survey templates or resolve template IDs. However, there is no explicit when-to-use vs alternative guidance, no exclusions, and no mention of prerequisite authentication.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that it sends an email, which implies a side effect, but it doesn't mention that this likely consumes credits (given the sibling get_credits), that the send is irreversible, or what happens if the recipient isn't on the list. For a mutating action, this is a significant transparency gap.

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 with no wasted words. It immediately states the core action and scope ('single', 'one recipient'), which is exactly what an agent needs to know first.

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 send action with no output schema and no annotations, the description is severely incomplete. It doesn't mention the side effects (credit consumption), prerequisites (recipient must be in the list), failure conditions (invalid email, nonexistent thermometer), or any return information. An agent has no way to predict the outcome or plan for errors.

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

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

Schema coverage is 57%, leaving three parameters (lastName, firstName, companyName) undocumented in the schema. The description adds nothing beyond the schema; it doesn't clarify the purpose of optional fields or how they affect the email. It doesn't compensate for the missing schema descriptions or provide examples of valid 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 description clearly states a specific action: 'Send a single Email Thermometer survey to one recipient.' This distinguishes it from sibling tools that retrieve data (get_thermometers, get_credits) or manage recipients (add_recipient_to_list, unsubscribe_recipient). The verb 'send' plus the resource 'Email Thermometer survey' makes the purpose unmistakable.

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 on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the recipient must already exist in the list, that a valid thermometerID is required, or that this consumes credits). It also doesn't state when not to use it, such as for bulk sending or when a blast ID is needed. The context is implied by the name but not explicitly 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?

With no annotations, the description must carry the behavioral disclosure burden. It reveals that the tool adds to an unsubscribe list, implying a mutating action, but it does not state whether the action is reversible, whether it requires special permissions, or what effect it has on future sends. For a write operation, this is a significant gap.

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 with no redundant words or filler. Every word contributes to identifying the action and target list.

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 tool with full schema coverage, the description plus schema is minimally adequate to make a correct call. However, there is no output schema and no mention of side effects, return behavior, or when to choose this over the similar add_recipient_to_list sibling, leaving clear gaps.

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

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

The schema already covers both parameters with 100% coverage: emailAddress is described as the email to unsubscribe and notify as whether to notify the account. The description adds no new parameter-level detail, so the baseline 3 is appropriate.

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

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

The description states a clear action ('Add an email address') and a specific resource ('the account's Customer Thermometer unsubscribe list'), so an agent can infer the tool unsubscribes an email. It does not explicitly contrast with the similar sibling customerthermometer_add_recipient_to_list, but naming the unsubscribe list provides enough 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 description gives no guidance on when to use this tool instead of a sibling, nor any prerequisites or exclusions. The only usage signal is the tool name and the action itself, which is not enough to route an agent among add_recipient_to_list and other list-related tools.

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