PuntoCasa MLS

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

No annotations are supplied, so the description carries the full burden and does little: it never states that this is a read-only search, whether results are paged, how many are returned by default, or what happens when zona is empty. The presence of an output schema relieves the need to explain return values, but the operational behavior (a limit of 10, fuzzy matching on zona, result ordering) is entirely undisclosed.

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 short and front-loads the core action before listing the parameters line by line. The telegraphic parameter glosses are efficient, though the missing subject/language mixing ('la red') is slightly opaque.

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 three-parameter, optional-everything search with an output schema, the description covers the two query parameters adequately. It falls short on limite, on what 'la red' refers to, and on routing versus the sibling tools, which is a meaningful gap for a tool that is likely an agent's entry point.

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, and it does partially: it defines zona as a place/neighborhood/town with three concrete examples and enumerates the accepted tipo values in free text, which the schema lacks. The third parameter, limite, is never mentioned, leaving its meaning and default of 10 undocumented.

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

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

The description names a specific verb and object ("Busca avisos" = search listings) and the examples confirm it targets real-estate ads. It does not, however, distinguish itself from the sibling get_aviso, which plausibly retrieves a single listing, so the agent must infer the split between search and fetch.

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

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

There is no explicit when-to-use or when-not-to-use guidance and the siblings (get_aviso, listar_subdominios, zonas_disponibles) are never mentioned. The only usage hint is that tipo is "(opcional)", which tells the agent nothing about choosing this tool over the 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?

No annotations are supplied, so the description carries the full behavioral burden. "Detalle completo" implies a read-only retrieval, but the description never states that it is non-mutating, whether authentication is required, or how missing/invalid hashes are handled. For a tool with zero annotation coverage this leaves meaningful gaps.

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

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

A single short sentence that front-loads the verb-like purpose and puts the identifier clarification in parentheses. Nothing is wasted and nothing is buried.

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 one required parameter and an output schema already documenting return values, the description covers what an agent minimally needs to invoke it correctly. It falls short only on error behavior and an explicit read-only statement, which would matter more if the tool were not a simple lookup.

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, and it does: it explains that the hash_id is the hash appearing in the /aviso/<hash> URL path, which is real meaning beyond the bare "Hash Id" property. It still does not specify the hash format or length, so a small gap remains.

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?

"Detalle completo de un aviso por su hash" names a specific resource (aviso) and the identifier used to fetch it, so an agent knows this is a single-item detail retrieval. It does not explicitly contrast with the sibling tools (buscar_propiedades, listar_subdominios, zonas_disponibles), though those operate on different resources, so confusion risk is low.

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 parenthetical "el de la URL /aviso/<hash>" gives genuinely useful guidance on where the hash comes from, which is the main practical question for calling this tool. However, there is no statement of when to use it versus a search/list tool, no prerequisites, and no note on what happens if the hash is unknown.

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

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

No annotations are supplied, so the description carries the full behavioral burden. 'Lista' implies a read-only operation, but nothing is said about authentication, error behavior for an invalid base domain, whether results are paginated, or the scale of the returned list. The domain gloss on 'subdominios' is the only added context.

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

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

A single well-formed sentence: verb and resource first, clarification second, concrete example last. No filler, no repetition of the tool name, and every clause adds information.

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

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

With one required parameter and an output schema that already documents return values, the description gives the agent enough to call this correctly: what is listed and what the input looks like. The remaining gap is behavioral (errors, result size, relation to sibling discovery tools), which is modest for a simple enumeration tool.

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

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

Schema description coverage is 0% and the single 'base' property is undocumented in the schema, so the description must compensate. It does partially, by supplying the example format 'merida.casa', which tells the agent the parameter is a fully-qualified domain name rather than a bare label — meaningful added value, though it does not state accepted formats beyond the example or whether a scheme/subdomain prefix should be excluded.

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

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

The description names a specific verb and resource ('Lista los subdominios') and disambiguates the term with a parenthetical gloss ('portales por lugar/tipo') plus a concrete example ('merida.casa'). It is clearly a read-only enumeration tool, though it does not contrast itself with siblings such as zonas_disponibles or buscar_propiedades.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of when a different sibling tool would be a better choice. An agent must infer usage purely from the tool name and the domain gloss.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the catalog contents but says nothing about read-only behavior, permissions, result size, pagination, or side effects. For a zero-parameter listing tool this is minimal but leaves important operational traits unstated.

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

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

The description is a single compact sentence with no wasted wording. It is front-loaded with the catalog framing and then enumerates the included domain structures.

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, has no parameters, and includes an output schema, so return-value details need not be in the description. Still, the description does not clarify scope relative to listar_subdominios or what 'avisos disponibles' means in practice. It is adequate but leaves some ambiguity for an agent choosing among siblings.

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

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

The tool has zero parameters, so there is no parameter semantics for the description to clarify. The schema coverage is 100%, and the baseline for a zero-parameter tool is 4.

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

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

The description identifies the resource as a network catalog containing base domains, groups, subdomains, and notices. However, it uses a noun phrase rather than a specific verb and does not explicitly say whether it lists, retrieves, or summarizes these items. It only partially distinguishes itself from siblings such as listar_subdominios and get_aviso.

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?

There is no explicit guidance on when to use this tool versus buscar_propiedades, get_aviso, or listar_subdominios. The catalog framing implies it is a broad listing tool, but no conditions, exclusions, or alternatives are stated.

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