Server Quality Checklist

Tool Scores

• plu_get_exchangeC
  2.2/5.0
  Behavior1/5

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

  No annotations are provided, and the description does not disclose behavioral traits such as read-only status, error handling for missing IDs, authentication requirements, or rate limits. This leaves the agent uninformed about critical behaviors.

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

  Conciseness2/5

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

  The description is extremely short (3 words), which could be considered concise, but it severely under-specifies the tool's purpose and usage. It does not earn its place by providing sufficient information.

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

  Completeness2/5

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

  Given the simplicity of the tool (one required parameter, no output schema), the description still lacks completeness. It does not mention return values, error scenarios, or any side effects, making it insufficient for safe and effective use.

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

  Parameters1/5

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

  Schema describes parameter 'exchangeId' with no description (0% coverage), and the tool description adds no meaning about what the ID represents or how to obtain it. The description fails to compensate for the missing schema documentation.

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

  Purpose4/5

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

  Description includes verb 'Get' and resource 'exchange details', clearly indicating it retrieves information about a single exchange. However, it does not differentiate from sibling 'plu_get_exchanges' which likely lists multiple exchanges.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives like 'plu_get_exchanges'. It implies usage when an exchange ID is known, but lacks explicit context or prerequisites.

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

• plu_delete_messageC
  2.4/5.0
  Behavior2/5

  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 merely states the action and mentions asking confirmation, but does not disclose whether deletion is permanent, reversible, requires specific permissions, or affects related data. This is insufficient for an agent to understand the tool's impact.

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

  Conciseness3/5

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

  The description is very short (two sentences), which achieves conciseness, but at the cost of missing essential details. The structure is acceptable but overly minimal for the information needed.

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

  Completeness2/5

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

  Given the simplicity of the tool (one parameter, no output schema), the description should be sufficient but is not. It lacks explanation of what messageId represents, the result of deletion, and any side effects. The agent cannot fully understand the tool's usage context.

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

  Parameters1/5

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

  With schema description coverage at 0%, the description must compensate but does not. The parameter messageId is not explained at all—no indication of its format, how to obtain it, or its significance. The agent has no semantic context beyond the schema's type definition.

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

  Purpose4/5

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

  The description clearly states the verb and resource: 'Delete a message.' This distinguishes it from sibling tools like plu_delete_conversation (deletes conversation) and plu_send_message (sends message). However, it does not specify that the message is identified by messageId, which is slightly vague.

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

  Usage Guidelines2/5

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

  The only usage guidance is 'IMPORTANT: ask user confirmation,' which is a mandatory instruction but does not provide context on when to use this tool versus alternatives like plu_delete_conversation or plu_delete_availability. No explicit when-to-use or when-not-to-use information.

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

• plu_delete_unavailabilityC
  2.4/5.0
  Behavior2/5

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

  Without annotations, the description must disclose behavior. It indicates the tool deletes data and mandates user confirmation, but does not explain side effects, authorization requirements, or whether the deletion is reversible.

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

  Conciseness3/5

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

  The description is very short (two sentences) and front-loaded, but it omits essential information. It is concise but at the expense of clarity and completeness.

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

  Completeness1/5

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

  Given one parameter, no output schema, and no annotations, the description is severely incomplete. It does not explain what an unavailability period is, how to get the ID, or what happens post-deletion. Sibling tools like 'plu_get_unavailabilities' exist but are not referenced.

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

  Parameters1/5

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

  The input schema has one parameter 'unavailabilityId' with no description. The tool description adds no meaning to this parameter, failing to explain what the ID represents or how to obtain it. Schema description coverage is 0%.

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

  Purpose4/5

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

  The description clearly states the tool deletes an unavailability period, which is a specific verb+resource. However, it does not differentiate from the sibling tool 'plu_delete_availability' beyond the name, which could cause confusion.

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

  Usage Guidelines2/5

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

  The description includes 'IMPORTANT: ask user confirmation' as a usage instruction, but provides no guidance on when to use this tool versus alternatives, such as when to delete availability instead, or prerequisites.

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

• plu_quick_searchC
  2.4/5.0
  Behavior2/5

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

  No annotations are provided, and the description does not disclose whether the tool is read-only, requires authentication, or what side effects exist. The minimal description fails to convey behavioral traits.

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

  Conciseness3/5

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

  The description is extremely concise at 3 words, but it is so brief that it sacrifices clarity and completeness. While it is front-loaded, it lacks sufficient detail.

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

  Completeness2/5

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

  Given the lack of output schema, no annotations, and only one parameter, the description fails to provide enough context about what the tool returns or how it differs from similar tools like plu_get_property.

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

  Parameters1/5

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

  With 0% schema description coverage, the description should add meaning to the parameter, but it only mentions 'listing number' implicitly. No explanation of format, range, or required format for the listing number.

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

  Purpose4/5

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

  The description clearly states the verb 'Search' and the resource 'listing number', and it distinguishes from the sibling tool plu_search_homes which likely searches by other criteria.

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

  Usage Guidelines2/5

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

  No usage guidance is provided. The description does not specify when to use this tool versus alternatives like plu_search_homes or plu_get_property.

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

• plu_cancel_exchangeC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It mentions cancellation is destructive and requires confirmation, but it does not detail reversibility, permissions, side effects, or 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.

  Conciseness4/5

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

  The description is very brief with two sentences, front-loading the purpose and a key warning. It is concise, though it could benefit from more detail on prerequisites.

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

  Completeness2/5

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

  Given a single required parameter and no output schema or annotations, the description fails to explain return values, error conditions, or prerequisites such as exchange state.

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

  Parameters1/5

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

  The input schema has 0% description coverage, and the tool description does not explain the 'exchangeId' parameter or how to obtain it.

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

  Purpose4/5

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

  The description 'Cancel an exchange' clearly states the verb and resource, and it is distinct from sibling tools like plu_create_exchange or plu_update_exchange_dates.

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

  Usage Guidelines2/5

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

  The description provides a warning to ask user confirmation, but no guidance on when to use this tool versus alternatives like plu_get_exchange or plu_update_exchange_dates.

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

• plu_search_homesC
  2.6/5.0
  Behavior2/5

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

  The description does not disclose any behavioral traits such as authentication requirements, rate limits, or side effects. With no annotations to provide safety hints, the description leaves the agent unaware of 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.

  Conciseness3/5

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

  The description is very concise at only three words, but it lacks structure. While it avoids verbosity, it is too brief to convey necessary information, balancing conciseness with adequacy.

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

  Completeness2/5

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

  Given the tool's 6 parameters, no output schema, and no annotations, the description is critically incomplete. It does not explain pagination behavior, return format, filter semantics, or required parameters, making it insufficient for reliable agent invocation.

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

  Parameters2/5

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

  The description adds no meaning beyond the input schema, which itself has 0% coverage (no parameter descriptions). Parameters like 'location', 'country', 'startDate' are named but their roles, formats, or constraints are not explained, forcing the agent to infer.

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

  Purpose4/5

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

  The description clearly states the verb 'search' and the resource 'homes', indicating a search capability. However, it does not differentiate from sibling tools like 'plu_quick_search' or 'plu_get_my_properties', which may also involve searching or listing properties.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, appropriate contexts, or scenarios where this tool is preferred over siblings such as 'plu_quick_search' or 'plu_get_exchanges'.

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

• plu_delete_availabilityC
  2.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It indicates a destructive mutation ('Delete') and a required user confirmation, but lacks details like irreversibility, error handling, or side effects.

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

  Conciseness4/5

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

  The description is extremely concise with one sentence and a warning. It front-loads the main action. However, it could benefit from minimal structuring (e.g., separate lines).

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

  Completeness2/5

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

  Given the lack of annotations, output schema, and parameter descriptions, the information is insufficient for confident usage. The description omits what the expected return value is, error scenarios, and how to obtain the availabilityId.

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

  Parameters1/5

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

  The description provides no explanation for the only parameter, availabilityId, despite 0% schema coverage. The agent must guess its meaning from the parameter name alone.

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

  Purpose4/5

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

  Description clearly states 'Delete an availability period' with a specific verb and resource. It distinguishes from sibling tools like plu_add_availability and plu_delete_unavailability. However, it could be more specific about the scope of deletion.

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

  Usage Guidelines3/5

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

  The description includes 'IMPORTANT: ask user confirmation', which provides a clear usage guideline for safety. But it does not specify when to use this tool versus alternatives, such as ensuring the availability exists before deletion.

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

• plu_delete_conversationC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits. It mentions 'delete/trash' and the need for user confirmation, but does not detail irreversibility, permissions required, rate limits, or other side effects. This is insufficient for an agent to understand the full impact.

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

  Conciseness4/5

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

  The description is concise with two sentences, no fluff, and the warning is prominently placed. The structure is effective for a simple tool.

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

  Completeness2/5

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

  Given the tool's destructive nature, the description should cover return values, prerequisites, and side effects. It lacks all of these, making it incomplete for safe and correct invocation.

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

  Parameters1/5

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

  The schema has 0% description coverage for parameters. The description adds no information about the chatId parameter beyond the schema's type and requirement, leaving the agent without guidance on how to obtain or format the ID.

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

  Purpose4/5

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

  The description clearly states the action (Delete/trash) and resource (conversation), distinguishing it from sibling tools like delete_message or delete_availability. However, it doesn't clarify the difference between 'delete' and 'trash'.

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

  Usage Guidelines3/5

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

  The description includes an important usage guideline: 'ask user confirmation.' This implies the tool is destructive and should be used with caution. However, it does not provide explicit context on when to use versus alternatives like delete_message.

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

• plu_update_exchange_typeC
  2.8/5.0
  Behavior2/5

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

  No annotations provided, so description must disclose behavioral traits. The confirmation instruction adds minimal transparency, but lacks details on side effects, reversibility, or authorization needs.

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

  Conciseness5/5

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

  Extremely concise: one sentence plus essential warning. No wasted words, front-loaded with action.

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

  Completeness2/5

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

  Given 2 required parameters and no output schema, the description is insufficient. It should clarify the effect of different swapTypes and what happens to the exchange.

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

  Parameters2/5

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

  Schema coverage is 50% (only swapType described), but the description adds no meaning for either parameter. It does not explain how the exchange changes or what swapType values imply.

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

  Purpose4/5

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

  The description 'Update exchange type' clearly states the action and resource, differentiating it from siblings like plu_cancel_exchange and plu_get_exchange.

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

  Usage Guidelines2/5

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

  The description only instructs to ask user confirmation, but provides no guidance on when to use this tool versus alternatives like plu_update_exchange_dates or plu_create_exchange.

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

• plu_auth_statusC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the burden falls on the description to disclose behavioral traits, but it is minimal. There is no mention of read-only nature, required prior authentication (e.g., cookies), or what the tool returns, leaving significant ambiguity.

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

  Conciseness3/5

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

  The description is extremely short at one sentence, which is concise but lacks structure or elaboration. While it is front-loaded, it may be overly minimal for effective use.

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

  Completeness2/5

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

  Given the trivial complexity (no parameters, no output schema, no annotations), the description is still incomplete. It does not explain what the status indicates, the return value format, or any constraints, making it insufficient for confident agent usage.

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

  Parameters4/5

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

  The input schema has no parameters, so the baseline is 4. The description does not add parameter-related info, but no parameters exist to describe, making this appropriate.

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

  Purpose4/5

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

  The description 'Check authentication status' uses a specific verb and resource, clearly indicating the tool's purpose. It is distinguishable from siblings like plu_login (authentication action) and plu_get_auth_user (user details), though it does not elaborate on what exactly is checked.

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

  Usage Guidelines2/5

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

  No guidelines are provided about when to use this tool versus alternatives such as plu_login or plu_get_auth_user. The description lacks context on prerequisites or the appropriate situation for checking auth status.

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

• plu_get_conversationsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavioral traits. It does not mention side effects (e.g., marking as read), permissions, rate limits, or pagination behavior beyond the parameter hint. The description is minimal and lacks transparency.

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

  Conciseness4/5

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

  The description is extremely concise—two brief sentences with no unnecessary words. It is front-loaded with the primary action. However, some detail could be added without harming conciseness.

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

  Completeness3/5

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

  Given the tool's simplicity (list with filters), the description is adequate but not complete. It lacks any mention of the return format, ordering, or how the output relates to sibling tools like 'plu_get_messages'. More context would improve agent decision-making.

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

  Parameters3/5

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

  The input schema provides descriptions for both parameters (page and filter), and the tool description adds value by enumerating possible filter values. However, it does not explain the effect of each filter, leaving interpretation to the agent.

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

  Purpose4/5

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

  The description clearly states 'Get conversation list' with a verb and resource. It lists specific filters ('unread', 'exchanges', etc.), which helps distinguish from other list tools. However, it does not specify the scope (e.g., user's conversations) and could further differentiate from sibling 'plu_get_messages'.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'plu_get_messages' or 'plu_get_exchanges'. There are no cues about prerequisites or when not to use it.

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

• plu_get_auth_userB
  3/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior. It only states 'Get authenticated user info', which implies the tool requires authentication and returns user info, but it does not specify what happens if the user is not authenticated, what exact data is returned, or whether it has side effects. The description is too vague to fully understand the tool's behavior.

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

  Conciseness4/5

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

  The description is very concise with a single phrase, which is efficient for a simple tool. However, it could be slightly more informative without sacrificing brevity, such as listing a few key fields of the user info. Still, it is not overly verbose.

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

  Completeness2/5

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

  Given the tool's simplicity (no parameters, no output schema, no annotations), the description is expected to provide more context about the returned data or its relation to other tools. It fails to do so, leaving the agent uncertain about what 'authenticated user info' entails.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description doesn't need to add parameter details, and the schema coverage is trivially 100%. No issues here.

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

  Purpose4/5

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

  The description clearly states the tool's action (Get) and resource (authenticated user info). However, it does not distinguish from the sibling tool 'plu_auth_status', which might serve a similar purpose, leaving ambiguity about when to use this tool over the other.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'plu_auth_status'. There is no mention of prerequisites, context, or exclusions, making it difficult for an agent to decide whether this tool is appropriate.

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

• plu_create_exchangeB
  3.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It adds the critical behavior that user confirmation must be obtained before invoking, but does not detail side effects, permissions, or response behavior.

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

  Conciseness4/5

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

  The description is very concise, with two short sentences. The important warning is front-loaded. It is efficient but could be slightly more informative without sacrificing brevity.

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

  Completeness2/5

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

  For a creation tool with no output schema and minimal parameters, the description lacks context about what happens after creation, what success looks like, or any implications. It is incomplete for a generation action.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the schema already documenting userId and propertyId as 'Partner user ID' and 'Partner property ID'. The description adds no further meaning beyond that.

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

  Purpose4/5

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

  The description clearly states the tool creates/proposes a new exchange, matching verb and resource. However, it does not explicitly differentiate from sibling tools like plu_get_exchange or plu_update_exchange_dates, but the purpose is specific enough.

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

  Usage Guidelines2/5

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

  The description includes an important instruction ('ask user confirmation') but provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

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

• plu_get_exchangesB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description should disclose behavioral traits, but it only states a generic action. It does not mention whether the tool is read-only, pagination, or any side effects. Minimal transparency.

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

  Conciseness5/5

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

  The description is a single, clear sentence with no unnecessary words. It is front-loaded and earns its place. Extremely concise.

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

  Completeness2/5

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

  Given the simplicity (no params, no output schema), the description is minimal. It does not explain what 'exchanges' are or if any filters apply. For a tool with many siblings, more context would help the agent choose correctly.

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

  Parameters4/5

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

  No parameters exist (schema coverage 100% with empty properties). The baseline is 4 per guidelines. The description adds nothing about parameters since there are none, which is appropriate.

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

  Purpose4/5

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

  The description 'Get my exchanges list' clearly indicates the verb (get) and resource (exchanges list), and the possessive 'my' suggests it's user-specific. It distinguishes from the sibling 'plu_get_exchange' which is singular. However, it could be more explicit about the scope.

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

  Usage Guidelines2/5

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

  No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like 'plu_get_exchange' or 'plu_create_exchange'. The agent must infer context from the tool name alone.

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

• plu_get_notificationsB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It only mentions JSON output but does not specify whether notifications are read-only, require authentication, or other behavioral traits.

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

  Conciseness5/5

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

  Extremely concise single sentence with no unnecessary words. Front-loaded appropriately.

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

  Completeness2/5

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

  No output schema, no parameter details, and minimal description. Lacks explanation of what notifications are included (e.g., user-specific or system). Incomplete for effective use.

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

  Parameters4/5

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

  No parameters exist, so schema coverage is trivially 100%. The description adds no additional parameter meaning, but baseline is 4 as per guidelines for zero parameters.

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

  Purpose4/5

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

  Description states 'Get notifications (JSON)' which clearly identifies the verb and resource. The name distinguishes it from siblings like plu_get_messages and plu_get_conversations, though no explicit differentiation is provided.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives. Lacks any context on prerequisites, when to use, or when not to use.

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

• plu_update_exchange_datesB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description should fully disclose behavioral traits. It states 'Update exchange dates' but does not clarify if the operation is destructive, requires authentication, or modifies existing data (overwrites vs. appends). The imperative to confirm hints at mutability but lacks detail.

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

  Conciseness5/5

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

  Two concise sentences with no filler. The critical instruction is highlighted via 'IMPORTANT' – front-loaded and efficient.

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

  Completeness3/5

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

  Given the lack of output schema and annotations, the description is minimally adequate. It states the action and a key requirement, but omits details about return values, error handling, and constraints (e.g., date ordering, timezones). An agent might need additional context to invoke safely.

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

  Parameters2/5

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

  Schema description coverage is 67% (format strings for dates, no description for exchangeId). The tool description adds no parameter-specific meaning beyond the schema, missing an opportunity to explain the relationship between start and end dates, valid ranges, or how exchangeId is obtained.

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

  Purpose5/5

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

  The description clearly states 'Update exchange dates' – a specific verb and resource. It distinguishes from sibling tools like plu_cancel_exchange, plu_create_exchange, etc., which deal with different aspects of exchanges.

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

  Usage Guidelines3/5

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

  The description includes 'IMPORTANT: ask user confirmation,' which provides explicit guidance on user interaction. However, it does not specify when to use this tool versus alternatives like plu_update_exchange_type, nor does it mention prerequisites or side effects.

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

• plu_add_availabilityA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, and the description only states the action and a confirmation requirement. It does not disclose behavioral traits such as side effects, idempotency, or required permissions.

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

  Conciseness4/5

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

  Description is concise and front-loaded with purpose, though it could be slightly more structured given the tool's parameter count.

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

  Completeness2/5

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

  With 7 parameters and no output schema, the description lacks context on return values, error handling, and prerequisites, making it incomplete.

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

  Parameters3/5

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

  Schema coverage is high (86%), and the description adds no additional meaning beyond what the schema already provides for each parameter.

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

  Purpose5/5

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

  The description 'Add an availability period' uses a specific verb and resource, clearly distinguishing it from siblings like 'plu_delete_availability' and 'plu_add_unavailability'.

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

  Usage Guidelines4/5

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

  Includes 'IMPORTANT: ask user confirmation,' which is a clear usage guideline, but lacks explicit comparison to alternatives or when not to use.

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

• plu_get_availabilitiesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses rate-limiting behavior, which is key for an API tool, but lacks details on error handling, null responses, or authentication requirements. The '(JSON API)' tag implies response format but adds little depth.

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

  Conciseness5/5

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

  Two sentences, front-loaded with purpose, followed by critical usage warning. No extraneous words.

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

  Completeness3/5

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

  For a simple tool with one parameter and no output schema, the description covers core purpose and one behavioral caveat (rate limits). However, it omits return format, pagination (if any), and error scenarios, leaving room for ambiguity.

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

  Parameters3/5

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

  Schema coverage is 100% for the single parameter 'propertyId', and the description adds no additional meaning beyond the schema's 'Property ID'. Baseline is 3 as per rubric.

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

  Purpose4/5

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

  The description clearly states the verb 'Get' and resource 'availability periods for a property', distinguishing it from mutation tools (add, delete) and the sibling 'plu_get_unavailabilities'. However, it does not explicitly differentiate from get_unavailabilities, relying on name contrast.

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

  Usage Guidelines3/5

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

  The description provides a useful rate-limit guidance ('prefer sequential calls'), but does not explicitly state when to use this tool versus alternatives (e.g., search or list tools). The guidance is performance-oriented rather than decision-oriented.

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

• plu_loginA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It only states 'Login' without disclosing what happens after (e.g., session creation, token return, side effects). The behavior is vague and lacks detail about the outcome or required permissions.

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

  Conciseness4/5

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

  The description is extremely concise with one sentence and an important note. It is front-loaded and to the point, but could be considered too brief for a login tool that might need more context.

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

  Completeness2/5

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

  With no output schema and no annotations, the description should explain what the tool returns or sets (e.g., session cookies). It only says 'login', leaving the agent uncertain about the outcome. This is insufficient for a login tool that likely has side effects.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents both parameters with basic descriptions. The tool's description adds no additional meaning beyond the schema, meeting the baseline but not exceeding it.

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

  Purpose5/5

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

  The description clearly states the tool logs in with email and password, which is a specific verb+resource. It distinguishes from sibling tools like plu_get_auth_user and plu_auth_status which deal with authentication state or user info, not login.

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

  Usage Guidelines4/5

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

  The description explicitly instructs to ask user confirmation before sending credentials, providing a clear usage guideline. However, it does not mention when not to use the tool or alternatives like plu_auth_status for checking login state.

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

• plu_send_messageA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It only mentions asking confirmation but does not disclose other behavioral traits such as delivery guarantees, rate limits, or permissions required. This is insufficient for a mutation tool.

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

  Conciseness5/5

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

  The description consists of two concise sentences with no wasted words. The purpose and important instruction are front-loaded, making it easy to scan.

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

  Completeness2/5

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

  There is no output schema, and the description lacks information about return values, error handling, or success/failure behavior. For a tool with 5 parameters and a mutating action, more context is needed to ensure correct invocation.

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

  Parameters3/5

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

  The input schema has 100% coverage with descriptions for all parameters. The description does not add any additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states 'Send a message to a user,' providing a specific verb and resource. It distinguishes itself from sibling tools like plu_get_messages and plu_delete_message, which are read/delete operations.

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

  Usage Guidelines4/5

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

  The description explicitly instructs 'ask user confirmation before sending,' which is a clear usage guideline. However, it does not specify when to use this tool versus alternatives, though for a send tool the context is implied.

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

• plu_get_my_propertiesA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention authentication requirements, what happens if the user has no properties, or any side effects. The word 'my' hints at authentication but does not explicitly state it.

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

  Conciseness5/5

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

  The description is a single concise sentence that immediately conveys the purpose. No unnecessary words, front-loaded with key action and object.

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

  Completeness3/5

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

  For a simple list tool with no parameters and no output schema, the description is minimal. It lacks details about authentication, return format, or pagination. However, it is adequate for a straightforward 'get list' operation given sibling context.

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

  Parameters4/5

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

  The input schema has no parameters, and the description adds no parameter-specific meaning beyond the schema. With 0 parameters, baseline score is 4 per guidelines.

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

  Purpose5/5

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

  The description 'Get my properties list' clearly states the verb 'Get', the resource 'my properties', and the result 'list'. It distinguishes from the sibling tool 'plu_get_property' which likely retrieves a single property.

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

  Usage Guidelines3/5

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

  The description implies usage for retrieving the user's own properties but provides no explicit guidance on when to use this tool versus alternatives like 'plu_get_property' or 'plu_search_homes'. No exclusions or prerequisites are mentioned.

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

• plu_get_propertyA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses rate-limiting behavior and server throttling/retry, adding value. However, it does not mention other behavioral aspects such as authentication requirements, side effects, or whether the response is cached, missing some context.

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

  Conciseness5/5

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

  The description is two sentences: the first states the purpose, the second provides essential usage guidance. It is front-loaded and contains no redundant information, earning high marks for conciseness.

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

  Completeness3/5

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

  Given the tool's simplicity (single parameter, public page), the description covers the basic purpose and a key behavioral consideration. However, it omits information about return structure, authentication context, and how 'public page' affects access, making it somewhat incomplete for an agent lacking output schema.

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

  Parameters3/5

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

  Schema coverage is 100% with a clear description for the single parameter 'propertyId'. The description adds no additional meaning beyond 'by ID', so it does not enhance understanding of parameter semantics beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action ('Get property details') and the resource ('by ID') with context ('public page'). It distinguishes from siblings like plu_get_my_properties and plu_search_homes, providing a specific verb-resource pair.

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

  Usage Guidelines3/5

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

  The description provides rate-limiting guidance and advises sequential calls, which is implicit usage context. However, it does not explicitly state when to use this tool versus alternatives like plu_get_my_properties or when authentication is needed, leaving comparative guidance absent.

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

• plu_get_unavailabilitiesA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior. It notes rate-limiting and JSON API, but lacks details on authentication requirements, error handling, or response format. Minimal disclosure beyond the rate-limit note.

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

  Conciseness5/5

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

  Two sentences: one for purpose, one for important usage note. No fluff, front-loaded, every sentence earns its place.

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

  Completeness3/5

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

  Simple tool with one parameter and no output schema. The description is adequate but could be enriched by differentiating from plu_get_availabilities or describing the return format. Given the complexity, it is minimally complete.

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

  Parameters3/5

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

  Schema coverage is 100% for the single parameter, so baseline 3. Description does not add any extra meaning beyond the schema's 'Property ID' description.

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

  Purpose5/5

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

  Clearly states 'Get unavailability periods for a property', which is a specific verb+resource. This distinguishes it from siblings like plu_get_availabilities (gets available periods) and plu_add_unavailability (mutation).

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

  Usage Guidelines4/5

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

  Provides a usage guideline about rate-limiting, suggesting sequential calls. However, it does not explicitly contrast with sibling tools like plu_get_availabilities for when to use which.

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

• plu_add_unavailabilityA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that this is a write operation requiring confirmation, but omits details on whether overlaps are allowed, whether it replaces existing data, or what the return value is.

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

  Conciseness5/5

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

  Two sentences, zero wasted words. The critical usage instruction is front-loaded after the action statement.

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

  Completeness3/5

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

  Adequate for a simple add operation: it states the action and a key usage requirement. Lacks details on behavioral aspects like conflict handling or output format, but given the tool's simplicity, it meets minimal viability.

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

  Parameters2/5

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

  Description adds no parameter-specific information beyond the schema. The schema already describes startDate and endDate formats; propertyId has no description and the tool description does not clarify it. With 67% schema coverage, the description compensates poorly.

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

  Purpose5/5

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

  The description clearly states 'Add an unavailability period,' which is a specific verb+resource. It distinguishes from sibling tools like plu_add_availability (adds availability) and plu_delete_unavailability (removes unavailability).

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

  Usage Guidelines4/5

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

  The instruction 'IMPORTANT: ask user confirmation' provides a clear usage guideline, implying the need for caution. However, it does not explicitly state when to use this tool versus alternatives or mention prerequisites.

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

• plu_get_messagesA
  3.8/5.0
  Behavior4/5

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

  Discloses rate-limiting behavior and suggests sequential calling, adding value beyond the schema. With no annotations, this description carries the full burden and does it well.

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

  Conciseness5/5

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

  Two sentences, front-loaded with purpose. No unnecessary words; every sentence provides value.

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

  Completeness4/5

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

  For a simple read tool with no output schema, description covers the main behavioral trait (rate-limiting). Could mention return format or pagination, but still adequate.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. Description adds no additional meaning to parameters beyond what the schema already provides.

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

  Purpose4/5

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

  Clear verb+resource: 'Get messages in a conversation thread'. Distinguishes from sibling 'plu_get_conversations' by specifying messages within a thread, though could be more specific about scope.

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

  Usage Guidelines3/5

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

  Provides a usage hint about rate-limiting and sequential calls, but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

• plu_set_cookiesA
  4.1/5.0
  Behavior2/5

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

  No annotations are provided. The description implies a mutation operation but lacks details on side effects, validation, or persistence. The burden is on the description, which minimally covers the action without deeper behavioral context.

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

  Conciseness5/5

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

  Two concise sentences with front-loaded purpose. Every sentence adds unique value: first states action and purpose, second provides practical retrieval instructions.

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

  Completeness4/5

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

  For a simple tool with one parameter and no output schema, the description is adequate. It covers purpose, parameter source, and usage context. Missing details on success/failure outcomes are minor given tool simplicity.

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

  Parameters5/5

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

  Schema coverage is 100% with description 'Raw cookie string'. The description adds significant value by specifying the exact source (DevTools → cookies → document.cookie), which is crucial for correct usage.

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

  Purpose5/5

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

  The description clearly states the verb 'inject' and resource 'raw browser cookies for authentication'. It distinguishes from sibling auth tools like plu_login and plu_auth_status by specifying the cookie injection method.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use (authentication) and how to obtain the cookies (DevTools). It does not explicitly exclude other scenarios but is sufficiently informative.

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