PropFácil

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds context by specifying that it deletes the list and its saved entries (cascade delete), and that it requires an authenticated user. This goes beyond the annotations by clarifying the scope of deletion and the authentication requirement.

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

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

The description is two sentences, front-loaded with the primary purpose and usage condition, followed by a clear exclusion. Every word earns its place; no fluff or redundancy.

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

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

Given the tool's simplicity (one parameter, no nested objects, output schema present), the description is complete. It covers the action, the condition (authenticated user), the scope (list and saved entries), and the exclusion. The output schema likely describes the result, so no need to explain return values. The only minor gap is that it doesn't mention what happens if the list doesn't exist, but that's not essential for selection.

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

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

The schema has only one parameter, listId, with basic constraints (string, minLength 1, maxLength 100). The description does not add any additional meaning about the parameter beyond what the schema provides. Since schema coverage is 0% but the parameter is self-explanatory (listId), the description doesn't need to elaborate. 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 clearly states the tool's purpose: to permanently delete a PropFácil favorite list and its saved entries when an authenticated user explicitly asks. It uses a specific verb ('delete') and resource ('favorite list'), and distinguishes from the sibling tool 'remove_property_from_list' by explicitly stating 'Do not use it for removing 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.

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

The description provides explicit when-to-use guidance: 'when an authenticated user explicitly asks to permanently delete one of their PropFácil favorite lists and its saved entries.' It also provides a clear exclusion: 'Do not use it for removing a single property,' which differentiates it from the sibling tool 'remove_property_from_list.'

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds that only authorized listings are accessible and that input must come from search_properties, which is useful behavioral context beyond the annotations.

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

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

The description is one concise, front-loaded sentence that gives the trigger condition, the input source, and the scope of the operation. There is no wasted wording or redundancy.

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

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

Given the single parameter, complete schema coverage, safe read-only annotations, and presence of an output schema, the description covers all necessary context. It fully communicates what the tool does, when it applies, and what input is needed.

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

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

Schema coverage is 100%, and the schema already explains that 'id' is a listingKey or listing ID returned by search_properties. The description essentially repeats this schema information, adding no new parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves details for one authorized PropFácil listing, using a listingKey or ID from search_properties. The verb 'get' plus the specific resource and prerequisite distinguishes it from sibling tools like search_properties or my_listings.

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

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

It explicitly says when to use the tool: when the user wants details for one listing and has supplied an ID from search_properties. It does not explicitly mention when not to use it, but the condition 'one authorized listing plus ID from search_properties' makes the usage context clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context by explaining that the tool enables contacting the advertiser or opening the original listing, which implies a navigation or disclosure action beyond a simple read. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence that states purpose and usage conditions without any fluff. Every phrase earns its place, making it highly concise and well-structured.

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

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

The tool is simple (one parameter, read-only, with an output schema). The description provides the necessary context—when to use it and the property provenance requirement—and the output schema handles return values, so nothing additional is needed.

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 covers 100% of the parameter's meaning, describing 'id' as a listingKey or listing ID from search_properties or get_property. The description itself adds no parameter-specific details, so the schema carries the burden, meeting the baseline of 3.

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

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

The description clearly states the specific action (contact advertiser or open authorized original listing) and the resource (property). It distinguishes itself from siblings like get_property (which retrieves property details) and search_properties (which searches) by specifying the exact trigger: 'when the user explicitly asks to contact the advertiser or open the authorized original listing.'

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

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

The description provides explicit usage context: 'when the user explicitly asks to contact the advertiser or open the authorized original listing' and restricts to 'a property previously returned by PropFácil.' It lacks explicit when-not-to-use or alternative tool references, but the trigger is unambiguous and the prerequisite is 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds useful context that the tool requires an authenticated user and applies to 'their' lists, implying ownership. This is valuable behavioral information for authorization handling. No contradictions found.

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 tool's purpose and usage context. No redundant words or unnecessary details. Perfectly sized for the tool's simplicity.

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

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

With an output schema present, return values don't need description. The tool has one simple parameter, read-only semantics are covered by annotations, and the description provides usage context. It adequately covers the tool's behavior given its low complexity, though it could mention error handling or prerequisites beyond authentication, but those are likely inferred.

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

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

Schema description coverage is 0%, so the description must compensate for the parameter 'listId'. It does so implicitly by stating 'one of their favorite lists', which suggests the parameter identifies the specific list. However, it doesn't explicitly define listId's purpose or format. Given the single required parameter and its self-explanatory name, the inference is straightforward, but the description could be more direct.

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

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

The description clearly states the tool's function: 'inspect one of their PropFácil favorite lists and its saved properties.' This is specific, uses a clear verb ('inspect'), identifies the resource (favorite list), and distinguishes it from siblings like list_property_lists (which lists all lists) and get_property (which fetches 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.

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

The description provides a clear 'when to use' context: 'Use this when an authenticated user wants to inspect one of their PropFácil favorite lists.' It implies the user is inspecting a specific list, not listing all lists or managing them. It doesn't explicitly mention alternatives, but the guidance is sufficient for an agent to select this tool over siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat those. It adds the scope detail that only lists owned by the linked user are returned, which is useful but not extensive behavioral context. It is minimal and does not contradict annotations.

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

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

The description is two sentences, front-loaded with the invocation condition and the key constraint. Every word serves a purpose, with no filler or repetition of schema/annotations.

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

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

Given the tool's simplicity (no parameters, output schema present), the description is adequate. It covers the purpose, authentication context, and user ownership. It does not mention pagination or result count, but the output schema likely covers return structure, so this is acceptable.

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 schema coverage is trivially 100%. Per rubric, 0 parameters gives a baseline of 4. The description does not need to explain parameters and does not attempt to.

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 'List their favorite lists' and 'returns only lists owned by the linked user', giving a specific verb and resource with user scoping. This distinguishes it from siblings like delete_property_list or search_properties.

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

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

It explicitly says 'Use this when an authenticated user wants to see their PropFácil favorite lists', providing a clear trigger. However, it does not mention when not to use it or alternative tools, such as get_property_list for a specific list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds user scoping (authenticated user) and status (published) but does not disclose additional behavioral details like pagination or return format. This matches the calibration level where annotations cover the safety profile.

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

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

A single sentence that is immediately actionable, with no filler or redundancy. Every word adds value.

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

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

For a zero-parameter tool with an output schema, the description provides enough context to know when and how to use it, and it differentiates from siblings. It could mention limitations (e.g., only published listings) but that is already stated. The presence of an output schema means return values need not be explained.

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 is empty (0 parameters), so the baseline is 4. The description correctly makes no parameter claims, and no additional parameter semantics are needed.

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

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

The description clearly states the tool lists property listings published by the authenticated user on PropFácil, using a specific verb 'review' and a clear scope. This distinguishes it from sibling tools like search_properties or list_property_lists, which have different purposes.

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

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

Provides explicit when-to-use guidance ('when an authenticated user asks to review the property listings they published'), but does not explicitly name alternatives or exclusions. The context is clear enough for an agent to select it over similar tools.

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

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

The description adds meaningful behavior beyond the annotations: it discloses that the action creates a public listing and is safe to retry with the same idempotencyKey. This complements the readOnlyHint=false and destructiveHint=false annotations without contradicting them.

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

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

The description is two sentences, front-loaded with the trigger condition, and every sentence provides useful guidance. There is no fluff or 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?

Despite having an output schema and annotations, this is a complex tool with 14 parameters, 6 required, and no parameter descriptions. The description only covers when to use it and idempotency, leaving significant gaps around required fields, transaction types, currency choices, and property attributes. It is not complete enough for reliable invocation.

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

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

Schema description coverage is only 7%, yet the description barely compensates. It only adds semantics for idempotencyKey via the retry-safety note, while the other 13 parameters—including required ones like transactionType, price, title, description, and city—remain unexplained.

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: publish a property publicly on PropFácil, creating a public listing. It uses a specific verb and resource, and it is distinguishable from sibling tools like save_property_to_list, get_property_list, and delete_property_list because it focuses on the publishing action.

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

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

The description gives clear context: use this when an authenticated user explicitly asks to publish a property publicly. It does not explicitly name alternatives or when-not-to-use scenarios, but the trigger condition is specific enough to guide tool selection among the listed siblings.

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

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

Annotations provide readOnlyHint: false and destructiveHint: false, so the tool is a mutation but not destructive to the list itself. The description adds that the list remains available if empty, which is useful behavioral context. However, it doesn't mention whether the operation is reversible, authentication requirements beyond implying user auth, or any side effects. With annotations covering the basic safety profile, this level is adequate.

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

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

The description is extremely concise: two sentences with zero waste. It conveys the purpose and a key behavioral detail (list persists when empty). Perfectly front-loaded.

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

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

This is a simple mutation tool with two parameters. The description covers the core functionality and a side effect. The output schema exists, so return values are documented. The only gap is that it doesn't mention authentication specifics, but that's implied by 'authenticated user'. For a tool of this complexity, it's complete enough.

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 0%, so the description must compensate. It mentions the tool removes a property from a list, which implies listId and propertyId are the identifiers for the list and property. However, it doesn't explicitly explain each parameter, but the function name and description make it obvious. Since the semantics are clear from context, a score of 4 is appropriate.

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

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

The description clearly states the action: remove a saved property from a PropFácil list for an authenticated user. It differentiates from siblings like delete_property_list (which removes the entire list) and save_property_to_list (which adds a property), though it doesn't explicitly name them.

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

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

It specifies when to use: when an authenticated user asks to remove a saved property from one of their lists. It doesn't explicitly mention when not to use it, but the context is clear. It could mention that delete_property_list is for deleting the whole list, but that's implied.

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

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

Annotations indicate it is not read-only and not destructive, and the description adds that the user must be authenticated. However, it does not discuss side effects of renaming (e.g., impact on saved properties) or reversibility.

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

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

The description is a single sentence with no extraneous words, directly conveying the purpose.

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 operation is simple and an output schema is present, so no return-value explanation is needed. The description covers the essential context, though it could mention potential effects on existing list contents.

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 description implies that listId identifies the list and name is the new name, but does not explicitly map them. With 0% schema coverage, this partial compensation is sufficient but not thorough.

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 (rename) and the resource (favorite lists), distinguishing it from sibling tools like save_property_to_list or remove_property_from_list.

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

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

Explicitly specifies when to use the tool (when an authenticated user asks to rename a list), but does not mention when not to use it or provide alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context that it renders interactive elements and requires pre-fetched IDs, reinforcing the read-only nature. No contradiction with annotations.

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

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

Two sentences, front-loaded with the key usage trigger and a clear constraint. No wasted words.

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

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

Given simple schema, annotations, and output schema presence, the description covers when to use and what to pass. Minor gap: title parameter is not addressed, but optional and low-risk. Complete enough for this tool's complexity.

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

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

Schema describes propertyIds well (up to 12 listingKey values from search_properties). Description reinforces that IDs must come from a data tool. However, title parameter is not explained in schema or description, and schema coverage is only 50%, so description doesn't fully compensate.

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

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

Description clearly states it is a presentation tool for showing interactive property cards, comparison, details, or a map after search_properties. It distinguishes from data retrieval siblings by implying rendering rather than data fetching, though it doesn't explicitly name an 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?

Explicitly states when to use ('after search_properties') and what to pass ('listing IDs already returned by a data tool'). Does not mention when not to use or name alternatives, but the context is clear and prescriptive.

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

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

Annotations already indicate readOnly and non-destructive behavior. The description adds the trigger context but does not disclose edge cases (e.g., behavior when no previous selection exists) or any side effects beyond the restoration itself. It adds moderate value beyond annotations.

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

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

The description is a single, clear sentence with no unnecessary detail or redundancy. It fully conveys the tool's purpose and condition without wordiness.

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 provides the main scenario and purpose. While it does not cover edge cases like absence of prior selection, the tool's simplicity and the existence of an output schema mean the description is adequately complete for its scope.

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

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

There are zero parameters, and schema coverage is effectively 100%. According to the baseline rule for zero-param tools, a score of 4 is appropriate; the description does not need to explain parameters.

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 (restore), the resource (latest public property selection), and the context (current MCP session after widget recreation). It effectively distinguishes from sibling tools like search or get by targeting a session-specific restoration.

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

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

Explicitly provides the trigger condition ('after its widget is recreated') and context ('needs to restore the latest public property selection'). Does not mention alternatives or when not to use it, but the condition is clear enough.

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

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

Annotations already indicate this is not read-only and not destructive. The description adds meaningful behavioral context beyond the annotations: the operation is idempotent and defaults to the list named 'Favoritos' when no list is provided.

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

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

The description is extremely concise: two sentences, no filler, and the key purpose is front-loaded in the first sentence. Every phrase contributes useful guidance.

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

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

The description covers the main trigger, default behavior, and idempotency, which is reasonably complete given the annotations and output schema. However, the relationship between listId and listName, and the note parameter, remain unexplained, leaving meaningful gaps for a 4-parameter 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 25%, so the description must compensate for the undocumented parameters. It partially does by explaining the default list behavior for the list-related parameters, but it does not clarify listId versus listName semantics or the purpose of the note parameter.

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

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

The description clearly states the tool's action: saving a property to a favorite list. It is specific about the resource ('property') and the operation ('save...to a favorite list'), and it differentiates from sibling tools like remove_property_from_list and delete_property_list.

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

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

It gives an explicit trigger condition: use when an authenticated user asks to save a property to a favorite list. It also provides guidance about the default list when none is supplied, but it does not explicitly mention when not to use the tool or point to alternatives.

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

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

The readOnlyHint and destructiveHint are already true/false from annotations, so the description doesn't need to restate them. The description adds the 'authorized' scope but doesn't explain behavior like pagination, result ordering, or error conditions. It is not contradictory but doesn't add much beyond annotations, so a 3 is appropriate.

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

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

The description is a single, clear sentence that immediately tells when to use the toolebb. It is concise and front-loaded with the usage trigger, avoiding unnecessary detail.

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

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

Given the number of parameters (8) and low schema coverage (25%), the description is somewhat incomplete. It doesn't explain the relationship between 'near' and 'radius' or the effect of combining filters. However, it provides a general purpose and the output schema exists, so it is minimally sufficient.

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

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

With only 25% schema coverage (only near and radius have descriptions), the description fails to explain the meaning of city, transaction type, price ranges, and bedroom filters. It mentions these categories generally but does not clarify how they are used or combined. This leaves the agent with insufficient parameter guidance.

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

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

The description clearly states the tool's purpose: searching property listings in Mexico by city, transaction type, price, bedrooms, or radius. It distinguishes itself from sibling tools like get_property or render_property_results by focusing on search functionality.

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

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

It provides a clear trigger condition ('when the user wants to find property listings') and lists the criteria for searching Poisson. However, it does not explicitly contrast with alternatives like get_property (retrieve a single property) or list_property_lists, but the context is sufficient for most agents. The description does not mention any limitations or when not to use it, but the clarity is high.

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