Metastate · Imóveis em Portugal

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

Annotations already declare this a safe, non-destructive, closed-world read, so the burden is low. The description adds real behavioral substance beyond that: which taxes are computed, the 0.8% stamp duty figure, the Casa Pronta registry fee, and the three scenario branches (primary residence, second home, under-35 exemption). It omits any caveats about estimation accuracy or output shape, but the output schema covers returns.

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?

Front-loaded and compact: the calculation, jurisdiction and rate year come first, followed by the covered instruments. The Portuguese sentence is near-verbatim duplication of the English and earns only partial credit, but the overall length remains tight and scannable.

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 moderately complex tax calculator with a full output schema, the description is sufficient: it establishes jurisdiction, year, components and eligibility branches. It stops short of noting the mainland-only limitation's consequence for island buyers or that figures are estimates, which leaves a small gap.

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

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

Schema description coverage is 100%, so each of the four parameters is already documented including enum meanings and the €330,539 exemption threshold. The description's mention of 'primary residence, second home, or under-35 exemption' mirrors the finalidade and comprador_ate_35 semantics without adding new syntax or edge-case meaning, so baseline 3 is warranted.

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?

States a specific verb (calculates) plus the exact resource (taxes and fees of buying a home), and narrows scope to mainland Portugal with 2026 official rates. It names IMT, stamp duty and land registry explicitly, so it is unmistakable against siblings like pesquisar_imoveis or ver_imovel, which do not compute costs.

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 2026 mainland-Portugal scope is useful context, but there is no explicit 'use this when...' routing and no mention of alternatives or when the tool does not apply (e.g., islands, older years). Usage is only implied by the resource name and the listed transaction scenarios.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context: the guide's content scope and the fact that its Golden Visa guidance reflects the post-Law 56/2023 rule that real estate no longer qualifies — signaling the info's currency and limits.

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 English sentence is dense, front-loaded, and earns every clause. The trailing Portuguese restatement is largely redundant for an agent, which keeps this just short of a 5.

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, the description needn't explain return values, and it does fully characterize the guide's coverage plus the one optional language param. Only the lack of routing guidance relative to siblings keeps it from a 5.

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

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

Schema description coverage is 100% and the single 'idioma' enum (en/pt) is documented in the schema, so the baseline is 3. The bilingual phrasing hints at language support but adds no semantics beyond what the schema already provides (e.g., default behavior).

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?

States a specific verb+resource ('Step-by-step guide for foreigners buying property in Portugal') and enumerates the exact topics covered: NIF, bank account, CPCV, taxes, deed, Golden Visa. An agent can distinguish it from calcular_custos_compra or pesquisar_imoveis without opening any schema.

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

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

Usage is only implied — an agent can infer this is the process/overview tool versus the cost or listing siblings, but the description never states when to choose it over calcular_custos_compra or falar_com_consultor, nor any prerequisites.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful source and data-scope context (INE, median sale price, buyer-origin and new-vs-existing splits), but it does not describe pagination, rate limits, or response behavior beyond what the output schema likely covers.

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 key purpose and source. The bilingual repetition is redundant for an English-reading agent but likely intentional for multilingual use, which slightly lowers the score from a perfect 5.

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

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

For a one-optional-parameter read-only statistical tool with an output schema and rich annotations, the description provides complete contextual framing: source, metric, geographic scope, and available data splits. Nothing needed to call it correctly is missing.

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

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

The single parameter 'zona' has 100% schema description coverage, including examples and the empty-string overview behavior. The description lists some regions but adds no meaningful syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: consulting official median sale price per m² of homes sold from Statistics Portugal (INE). It lists the covered regions and data splits, allowing an agent to distinguish it from property listing or cost-calculation siblings without opening schemas.

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

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

Usage is implied by the stated purpose (retrieving official market price statistics), but there is no explicit when-to-use guidance, no mention of when not to use it, and no named alternatives among siblings like pesquisar_imoveis or calcular_custos_compra.

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=false, destructiveHint=false and openWorldHint=true, so the agent knows this is a non-destructive outward-facing write. The description confirms a 'contact request' is submitted but adds nothing about what happens downstream (notification, response time, whether consent is validated server-side), so it earns only modest credit 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?

Two short sentences, front-loaded with the core action, and the bilingual pair is a reasonable choice for a Portuguese-market tool. The Portuguese sentence is largely a restatement of the English one, which costs a little efficiency.

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, annotations covering the safety profile, and 100% schema coverage, the description need not explain returns or parameters. It is complete enough to invoke correctly, missing only downstream behavior of the submitted request.

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

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

Schema description coverage is 100%, so all eight parameters including the RGPD consent flag and the interesse enum are already documented in the schema. The description adds no parameter-level meaning, which is the expected baseline when the schema does the work.

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?

States a concrete verb and resource: 'Leaves a contact request for a Metastate consultant', with the supported intents (buy, sell, rent, other) enumerated. It is distinguishable from read-oriented siblings like pesquisar_imoveis or ver_imovel, though it never names how it differs from nearby write siblings such as marcar_visita or pedir_avaliacao.

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

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

Usage is implied — the agent can infer this is for when a user wants to be contacted by a consultant — but there are no explicit when/when-not conditions and no routing to alternatives like marcar_visita. The language list implies applicability to multilingual users but isn't framed as guidance.

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 that the response includes the canonical URL for citation, but says nothing about pagination, content size, or failure modes for invalid ids.

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

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

A single front-loaded sentence with a useful parenthetical enumerating the content kinds; no filler. Slightly dense but everything earns its place.

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

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

For a one-parameter read tool with an output schema already covering return values, the description supplies the essential scope (what content is fetched, id provenance, citation URL). Little is missing beyond usage routing.

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

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

Schema description coverage is 100% and the single id parameter is fully documented with format examples, so the baseline of 3 applies. The description adds no syntax or meaning beyond what the schema already provides.

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?

States a specific verb (fetch) and resource (full content of a search result by id), and clarifies the two content types: property listing details or guide text. It is clear enough to distinguish from search(), though it does not explicitly address overlap with ver_imovel.

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 id format in the schema (returned by search) implies usage after a search call, but the description itself gives no explicit when-to-use or when-not guidance versus siblings like ver_imovel or pesquisar_imoveis.

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?

Adds real value beyond the annotations: the viewing is NOT confirmed automatically and the consultant must contact the user to confirm date/time. This is exactly the kind of workflow context annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) cannot convey. It omits failure/error behavior or rate limits.

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?

Short and front-loaded: the core action comes first, the confirmation caveat second. The bilingual duplication adds length without adding information, a minor inefficiency in an otherwise tight definition.

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?

An output schema exists, so return values need not be explained, and the schema fully covers consent (RGPD) and contact rules. Combined with annotations, the description supplies the remaining behavioral nuance; only the absence of failure/permission handling keeps it short of complete.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters including the consent and contact requirements. The description adds no syntax or format detail beyond what the schema provides; baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Registers a viewing request for a property.' This is clearly distinguishable in intent from siblings like pedir_avaliacao or ver_imovel, though the description never explicitly names or contrasts with any sibling tool.

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

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

Usage is implied by the purpose ('registers a viewing request'), and it clarifies the follow-up workflow (consultant confirms). However, it gives no when-to-use vs alternatives guidance, e.g. when to choose this over falar_com_consultor, which is a close sibling.

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 usefully discloses behavior beyond the annotations: it triggers a follow-up from a consultant and produces only an indicative range, not a formal valuation. That goes beyond readOnlyHint=false/openWorldHint=true by explaining the lead-capture consequence, though it does not state auth or data-handling limits beyond what the schema's GDPR field implies.

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 compact sentences that lead with the core outcome and append the consultant follow-up, so nothing is buried. The bilingual duplication adds length without new information for an English-reading agent, a minor inefficiency.

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 need no explanation, and the description covers the key side effect (consultant contact) and the scope of the estimate. What is left out is the decision context against sibling tools, which is modest given the schema's completeness.

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%, so all eight parameters, including the mandatory GDPR consent with its privacy-policy URL, are already documented in the schema. The description adds no syntax, format, or default guidance beyond that baseline.

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?

States a specific resource and what it returns: an indicative sale value range for a Portuguese property derived from comparable listings, plus a consultant follow-up. The purpose is unambiguous, but it does not explicitly name how it differs from siblings like consultar_precos_mercado or falar_com_consultor, which cover adjacent ground.

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

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

Usage is implied by the description (a homeowner wanting a quick price estimate and onward contact), but there is no explicit when-to-use guidance, no exclusions, and no routing to the semantically close siblings consultar_precos_mercado and falar_com_consultor. An agent must infer the choice.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds the notion of a 'live portfolio' (freshness/dynamic data), but adds nothing about pagination, result ordering, or rate limits. With annotations carrying the safety burden, this is adequate but thin.

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

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

The quote of return fields (reference, title, operation, price, type, size, area and listing link) is redundant given a full output schema, and the bilingual duplication roughly doubles the length. It is front-loaded and readable, but some sentences do not earn their place.

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

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

For a 13-parameter, all-optional search tool with full schema coverage, an output schema, and read-only annotations, the description covers scope, geographic footprint and operations. Only minor routing/behavior context is missing, so it is close to complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only restates two concepts already fully documented in the schema (operation = sale/rent, price or monthly rent); it adds no syntax, defaults, or interaction semantics for the 13 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?

States a specific verb and resource (search available homes and commercial properties in Metastate's live portfolio in Portugal), names the geographic scope and the two operations (sale/rent). An agent can distinguish it from siblings like ver_imovel (single listing) and consultar_precos_mercado without opening any schema.

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

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

Usage is implied by naming the portfolio and operations, but there is no explicit when-to-use guidance or routing away from alternatives such as ver_imovel or marcar_visita. A capable agent can infer intent, but nothing is stated about when this tool is the wrong choice.

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, non-destructive and non-open-world, so the safety profile is covered. The description adds real behavioral context beyond that: it says the result set is ids/titles/canonical URLs and that this is a two-step search-then-fetch flow, which tells the agent not to expect full content here.

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

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

Three tight sentences: purpose first, return shape second, follow-up action third. No filler, and the most decision-relevant information (what it indexes and how to continue) is 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?

A 1-parameter read-only tool with annotations and an output schema needs little more than this; the description covers scope, return entry points, and the fetch handoff. The only gap is the unexplained relationship to the overlapping property-specific search 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?

Schema description coverage is 100% for the single query parameter, and the schema already gives natural-language examples ('3 bedroom for sale in Lisbon with garage', 'IMT costs'). The description adds no formatting, length, or syntax detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource: free-text search over the live property portfolio plus guides (INE prices, purchase costs, foreign-buyer guide). The scope note that it covers both properties and editorial guides implicitly distinguishes it from the narrower siblings like pesquisar_imoveis and consultar_precos_mercado, but no sibling is named explicitly.

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 workflow guidance (use fetch with an id to get full content) and frames itself as the standard search/fetch entry point for deep research. However, it never states when to pick this over pesquisar_imoveis or consultar_guia_estrangeiro, leaving the routing decision to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safe-read profile is covered. The description adds only that the lookup accepts a reference or slug, without disclosing auth needs, pagination, or error behavior for a missing reference.

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?

Front-loaded with the core action, and the field list is compact. The bilingual duplication roughly doubles length without adding information, keeping it just below top marks.

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 and 100% schema coverage, the description need not explain return values, and it is adequate for a simple one-parameter read tool. It could be slightly stronger by noting behavior when the reference is invalid.

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 single parameter is fully documented in the schema, including the origin of the reference. The description adds only the META-003 example, which is marginal beyond what the schema already conveys, so baseline 3 applies.

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

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

States a specific verb (view full details) and resource (one property) and enumerates the returned fields, which clearly distinguishes it from the search sibling pesquisar_imoveis. It does not name the alternative explicitly, but the single-property lookup framing is unmistakable.

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

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

The description implies usage ('by reference or slug') and the schema notes the reference comes from pesquisar_imoveis, so an agent can infer this is the detail-view follow-up to a search. However, no explicit when-to-use or when-not-to-use guidance or named alternatives are given.

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