Malta MPRP Guide

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered and the description does not need to restate it. The description adds useful scope detail by enumerating what the estimate itemises (fees, contributions, property minimums). It says nothing about defaults being applied, sensitivity of the result, or the shape of the returned estimate.

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 with no filler, front-loading the deliverable (itemised estimate) before the inputs that drive it. Nothing is repeated from the schema or annotations and every clause carries meaning.

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 12-parameter calculation tool with no output schema, the description conveys the general output but not its structure or units, and adds no guidance on how the many optional parameters interact. It is adequate to call the tool, but an agent gets no help on interpreting or relying on the result.

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 83%, so the schema already documents nearly every parameter, including defaults and the programme-minimum fallback for purchase_price and annual_rent. The description's 'family composition and property route' phrasing only loosely gestures at the parent/child/spouse parameters. With the schema doing the heavy lifting, the baseline 3 is appropriate.

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

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

The description names a specific computation (itemised estimate of government fees, contributions and property minimums) over clearly stated inputs (family composition, property route). It is unambiguous what the tool produces. It does not, however, distinguish itself from nearby siblings such as cost_of_living, malta_statistics, or get_mprp_programme, so an agent must infer the boundary.

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 states the inputs the estimate is based on but gives no explicit when-to-use guidance, no conditions under which an alternative (e.g. get_mprp_programme for programme rules, cost_of_living for general expenses) is preferable, and no prerequisites. Usage is only implied by the phrase 'for a given family composition and property route'.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value by disclosing the return content (ranges, dates, sources), which matters since no output schema exists, but it says nothing about locality fallback behavior, data freshness, or caching.

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 dense sentence that front-loads the resource and geographic scope before the parenthetical list of covered domains. No filler and nothing repeated, though the parenthetical enumeration is somewhat list-heavy.

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 no output schema, the description carries the burden of describing results, and it does so only partially (ranges, dates, sources). Coverage of two optional parameters plus no output schema means a slightly richer description would help, but nothing critical for a correct invocation 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?

Schema description coverage is 100% and both parameters are documented there, so the baseline is 3. The description's category list loosely maps to the enum values (with FAMILY/LIFESTYLE rendered as 'education'/'leisure' rather than the actual enum names) and says nothing about the locality parameter's national-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?

The description names a specific resource (typical monthly costs in Malta and Gozo) and enumerates the cost domains covered (housing, utilities, food, transport, healthcare, education, leisure), which are concrete and verifiable. There is no verb, and it does not distinguish itself from the sibling malta_statistics, so it falls short of a 5.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as malta_statistics or calculate_mprp_cost. The agent must infer that this is a reference/lookup tool from the phrasing alone.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description earns credit for adding behavioural context beyond that: the exact return shape (Markdown plus author, reviewer, last-verified date, official sources), which matters since there is no output schema.

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, zero filler, and front-loaded with the payoff (returned format and provenance) before the accepted inputs. Nothing redundant with the name or title.

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 single-parameter read tool with no output schema, the description supplies the return content that would otherwise be missing and enumerates valid input forms. It omits failure behaviour (invalid id, unreachable URL), which is a minor gap given the rich annotations.

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 parameter's description already enumerates the accepted forms, including the programme/<...> enum-like section list. The description restates these forms in prose without adding format, validation, or error semantics, 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?

The description states a specific verb and resource ('Returns one document as Markdown') and lists the return payload (provenance, sources), so the agent knows exactly what comes back. It stops short of distinguishing itself from near-neighbours like get_mprp_programme or list_content, both of which could plausibly return document-like content.

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 rather than stated: accepting 'a search result id' hints that this follows a search call, and the accepted input forms are enumerated. However, there is no explicit when-to-use guidance, no exclusions, and no routing against the sibling tools that also serve programme/property content.

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, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds that the data is 'verified' and carries effective dates and legal references, which signals authority and currency, but says nothing about caching, scope limits, or freshness beyond that.

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?

One dense sentence that front-loads the core claim ('The verified programme data') and then lists contents. Every clause maps to a real section of the tool, though the trailing enumeration is long enough to border on a data dump.

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

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

For a read-only, single-enum-parameter facts tool with a full schema and no output schema, the description adequately signals what is returned by listing the content categories. Missing only language/locale or versioning caveats, which are not clearly needed here.

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 enum parameter is fully documented in the schema, so the baseline is 3. The description's content list loosely maps onto the enum values (fees, requirements, process, documents, dependants), adding marginal value but no formatting, default, or selection guidance beyond the schema.

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 resource (MPRP programme data) and enumerates its contents: property thresholds, fees and contributions, requirements, application steps, documents, dependant rules. That lets an agent distinguish it from siblings like calculate_mprp_cost or get_property. It stops short of explicitly naming an alternative, but the resource is unambiguous.

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 when-to-use instruction, no prerequisite, and no mention of alternatives such as calculate_mprp_cost for cost computations. The content list implies what the tool covers but leaves routing entirely 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely non-obvious content context: the response includes the MPRP threshold check and enquiry instructions, which the agent could not infer from the annotations alone.

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?

One tight sentence, front-loaded with the action and resource, followed by the identifier forms and notable response contents. No filler, though it is terse enough that it omits any usage or error nuance.

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 no output schema, the description usefully flags what matters in the return (MPRP threshold check, enquiry path). For a one-parameter read tool this is nearly complete; only error/invalid-reference handling is unaddressed.

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 parameter is fully documented (reference, slug, or URL). The description's '(e.g. P-1206) or slug' merely echoes the schema, adding no format or validation detail beyond it. 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?

Clear specific verb+resource: retrieves full details of a single listing, identified by reference or slug. The scope 'one listing' contrasts implicitly with the list/search siblings, though 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?

Usage is implied by the identifier requirement – call it when you already have a reference/slug. There is no explicit guidance on when to prefer it over search_properties or list_content, and no stated failure behavior for an unknown reference.

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 cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds no behavioral context beyond that—no mention of pagination, result format, or constraints—so it fails to enrich the agent's understanding of how the tool behaves.

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 and front-loaded with the verb, so it is concise. However, its content is largely a redundant enumeration of the schema enum values, which does not earn its place as additional 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?

For a simple listing tool with a fully described schema and comprehensive annotations, the description is minimally adequate. It lacks usage guidance and does not describe the return format, but the absence of an output schema and the richness of structured fields keep it at a minimum viable level.

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 parameters thoroughly, including the enum and defaults. The description merely repeats the type values and adds no meaning beyond what the schema provides, justifying the baseline score.

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

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

The description uses a clear verb ('Enumerates') and lists specific content types, so the basic action is discernible. However, it does not explain what these content types represent or differentiate the tool from siblings like search or fetch, leaving the purpose vague beyond a raw enumeration.

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

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

No guidance is provided on when to use this tool versus alternatives such as search or fetch. The description neither states conditions for use nor excludes scenarios, leaving the agent to infer usage entirely.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the remaining burden is light. The description usefully discloses the returned payload shape (value, period, methodology, official source) — information that exists nowhere else, since there is no output schema.

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?

One sentence, front-loaded with the resource and then the returned fields. No waste, though the trailing ellipsis-format category list is slightly loose compared to the schema's fixed enum.

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?

Adequate for a zero-required-parameter lookup: the payload is described and the schema covers all inputs. It falls short on routing (no differentiation from cost_of_living/search) and on hints about how key and category interact or what happens when a statistic is not found.

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 four parameters (key, category, locality, overview_only) are already documented in the schema, including the fallback behavior of locality. The description adds nothing beyond that baseline, which is the expected 3 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 specific resource (verified Malta statistics) and enumerates the domains covered (population, economy, prices, housing, climate), so an agent knows exactly what data it returns. It does not, however, distinguish itself from the sibling cost_of_living or search, which overlap in subject matter.

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

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

The description gives no when-to-use guidance, no prerequisites, and never mentions the alternatives (cost_of_living, search, fetch). An agent must infer from the name alone that this is the general-purpose statistics lookup rather than the cost-of-living tool.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the one behavioral fact the annotations cannot convey and that no output schema exists to convey: the result is a set of ids intended for `fetch`, which shapes how the agent must chain calls.

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 tight sentences: scope first, output contract second. No filler, no restatement of the title, and the most important operational fact (returns ids for fetch) is not 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 no output schema, the description carries the return-value burden and does so minimally but sufficiently by stating it returns ids for `fetch`. Ranking behavior, result count/pagination beyond `limit`, and behavior on empty results are unstated, which is a minor gap for a search 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 100% – both `query` (with examples and length bounds) and `limit` (range and default) are fully documented in the schema. The description adds nothing about parameter syntax or semantics beyond enumerating content types, 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?

Names a specific verb (full-text search) and enumerates the corpus it covers, so the agent knows this is a broad, cross-content search rather than a single-resource lookup. It does not, however, distinguish itself from the sibling search_properties, and explicitly listing 'property listings' in its scope blurs that boundary.

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 closing clause 'Returns ids for `fetch`' implies the intended workflow (search, then fetch by id), which is real usage guidance. But it never states when to prefer this over search_properties or list_content, nor any exclusions, so the routing decision is left 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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuine context by naming the single upstream feed (RE/MAX Lux) and the 'current' freshness expectation, reinforcing the closed-world hint. It says nothing about pagination behaviour or result caps, so it is useful but not rich.

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 with the resource and source front-loaded and the filter dimensions packed into a compact clause. No filler, though the trailing filter list borders on restating the schema.

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

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

For a 12-parameter, zero-required search tool with no output schema, the description covers source and filter scope but omits what a result looks like (list vs paginated envelope), default scope when listing_type is omitted, and result-count behaviour. Annotations cover safety, but the return-side gap leaves the definition only minimally 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 83%, above the threshold where the schema carries the load, so 3 is the baseline. The description does summarise the filter set (sale/rent, locality, price, bedrooms, MPRP threshold) matching listing_type, locality, min/max_price, bedrooms and mprp_eligible, but adds no syntax, unit or range detail beyond what the schema already documents and omits query, sort, page, property_type and special_designated_area.

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 (current property listings), names the data source (RE/MAX Lux feed), and enumerates the filterable dimensions, which lets an agent distinguish it from siblings like get_property or calculate_mprp_cost. It stops short of explicitly naming which sibling handles single-listing retrieval, so it is clear but not sibling-differentiated at a 5 level.

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 a browsable search over listings but gives no when-to-use framing, no guidance on when to prefer get_property for a single listing, and no exclusions. An agent must infer routing from the sibling names alone.

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 the write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the safety bar is lower. The description adds two things annotations cannot: the consent precondition and the return behavior ('Returns a reference only'), which matters because no output schema exists. It still omits any note on duplicate submissions, retries, 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?

Two tight sentences with zero filler; the purpose is front-loaded and the return-value caveat closes it out. Nothing is redundant or padded.

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 an 8-parameter, 4-required submission tool with no output schema, the description covers purpose, the consent precondition, and the return shape. It leaves out what happens after submission (follow-up, storage, error handling), which is minor but not fully covered.

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 88%, so the schema already documents the parameters thoroughly. The description only echoes the consent field and adds no format, default, or constraint detail beyond it — baseline 3 is appropriate 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 — 'Sends a consultation or property enquiry to the platform's consultants' — which is concrete and actionable. It is implicitly distinct from all read-only siblings (search, get_property, calculate_mprp_cost), but it never explicitly differentiates itself or routes the agent, so it falls short of a 5.

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?

'On behalf of a user who has given explicit consent' implies the precondition for use, but there is no explicit when-to-use vs when-not guidance and no alternatives are named. Usage is inferable rather than stated.

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