payotte-mcp

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

No annotations are provided, so the description carries the full burden. It thoroughly discloses data sources (CMHC, Bank of Canada), assumptions (20% down, 25-year amortization, etc.), and return values (cash outlay vs economic cost). There is 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 paragraph of four sentences. It efficiently conveys the tool's purpose, inputs, assumptions, and outputs without unnecessary 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 the tool's single parameter and no output schema, the description fully covers what the agent needs: when to use, what data is used, assumptions, and what the tool returns. It also addresses the limitation about CMHC coverage.

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 parameter 'ville', and the schema provides a basic example. The tool description does not add additional semantics beyond what the schema already provides, so it earns the baseline score 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 explicitly states that the tool compares renting vs buying in a Canadian city, using specific metrics (average rent and carrying cost). It uniquely addresses the rent vs buy question, distinguishing it from sibling tools like taux_courants or contacter_expert.

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 clearly states when to call the tool ('when the user wonders whether to rent or buy in a Canadian city') and notes a limitation ('Only cities inside a CMHC-covered metro have rent data'). It implies when not to use (if city is not covered), but does not provide explicit 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?

With no annotations provided, the description fully discloses the critical double opt-in behavior: the tool sends a confirmation link to the user's email, the expert is only contacted after the user clicks it, and the link is valid for 48 hours. It also details prerequisite steps, the need for explicit approval, and that Payotte keeps no copy of the content—far exceeding typical transparency.

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 densely packed with essential safety and workflow information, each sentence serving a purpose. It uses clear headings and a numbered list, making it easy to parse despite its length. 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 the tool's complexity—9 parameters, 6 required, no output schema, and no annotations—the description is exceptionally complete. It covers the full user journey, consent mechanics, privacy aspects, and potential pitfalls, leaving no critical operational detail 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 coverage is 100%, so baseline is 3, but the description adds meaningful parameter context: it explicitly instructs setting 'consentement' to true only after explicit approval, references collecting client name/email/message, and warns against inventing contact details. This goes beyond the schema's basic descriptions.

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: contacting a Payotte-listed professional when the user explicitly asks to reach out or request a quote/appointment. It distinguishes itself from the sibling 'trouver_expert' by noting when to call this tool instead.

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 says 'Call this ONLY when the user explicitly asks to contact, reach out to, or request a quote/appointment'. It also instructs to use 'trouver_expert' first if needed, providing clear when-to-use and alternative 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?

With no annotations provided, the description fully discloses the tool's behavior. It details the calculation methodology (stress test, GDS ratio, down payment, amortization, taxes, heating), cites a public source for methodology, and clarifies it is a theoretical threshold, not a loan offer. All relevant behavioral traits are covered.

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 concise (around 4 lines) and front-loaded with the usage trigger. Every sentence adds value: trigger, methodology summary, source reference, and caveat. No unnecessary 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 the tool's complexity (multiple assumptions) and lack of an output schema, the description explains what is computed and the methodology. It does not explicitly state the output format (likely a number), but from context it is clear. The completeness is high but could be slightly improved by specifying the return type.

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 the baseline is 3. The description adds some context (e.g., 'prix' is optional to test an alternative price), but the schema already documents both parameters adequately. No additional semantic meaning beyond what the schema provides is present.

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 compute the income needed to buy a home in a Canadian city. It uses a specific verb ('computes') and a specific resource ('reference home'). It distinguishes from sibling tools like acheter_ou_louer (buy vs. rent) and taux_courants (current rates), as this tool is solely for income qualification.

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 explicitly states when to use the tool: 'Call this when the user asks what income is needed to buy a home in a Canadian city.' It provides clear context but does not mention when not to use it or suggest alternatives, though sibling tool names offer some implicit differentiation.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It thoroughly describes what data will be returned, including the conditional inclusion of CMHC housing starts and StatCan New Housing Price Index for covered metro areas. It also discloses data sources and that each block lists its sources, providing transparency about the tool's data provenance.

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 core purpose and metric list, followed by conditional details and source attribution. Every sentence adds value, with no wasted words, making it highly efficient.

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 no output schema, the description enumerates all key return metrics (reference price, yoy change, sales volume, months of inventory, days on market, 5-year growth) and explains the conditional extra data. It also clarifies the geographic scope and data sources, providing a complete picture for an agent to invoke the tool correctly.

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% for the single 'ville' parameter, providing examples. The description adds meaningful context by specifying the tool is for Canadian cities and that metro-area coverage affects additional outputs, which goes beyond the schema's basic description.

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: retrieving current housing-market statistics for a Canadian city, listing specific metrics (reference price, yoy change, sales volume, inventory, days on market, 5-year growth). It distinguishes itself from sibling tools by focusing on market data rather than buying/renting advice, rates, taxes, or expert contact.

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 explicitly says 'Call this for current housing-market figures' which provides clear context for when to use it. However, it does not explicitly state when not to use it or name alternative tools for other types of queries, though the specificity implies alternatives exist for other purposes.

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 full burden. It discloses that data is read live from Bank of Canada API, each figure has its own observation date, and mortgage figures are system averages, not offers. This gives essential interpretation 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?

Four sentences, each adding substantive information: content enumeration, data source, caveat, attribution. No filler.

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 read-only tool, the description covers content, source, freshness, and interpretation caveat. No output schema needed since values are standard interest rates.

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?

Tool has zero parameters, so schema coverage is complete. Baseline 4 applies; description adds no parameter-specific info 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?

Clearly specifies the tool returns current Canadian reference interest rates, listing exact instruments (policy rate, prime, mortgage averages, bond yields). The verb 'Call this for' and specific list distinguish it from sibling real-estate tools.

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 begins with 'Call this for...' and enumerates the exact use case. No alternatives are mentioned, but sibling tools cover other real-estate topics, so the context is unambiguous.

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?

Without annotations, the description discloses key behaviors: bracket-by-bracket computation from official schedules, inclusion of first-time-buyer rebates, and coverage of specific provinces and cities. It notes that Alberta and Saskatchewan charge no tax. Missing detail on output format, but overall transparent.

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 focused sentences: first gives purpose and trigger, second details computation and coverage, third explains parameter usage. No wordiness, each sentence earns its place. Front-loaded with the primary action.

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 effectively covers what the tool does, what inputs it expects, and its geographic scope. However, it omits any hint about return values (since no output schema exists), such as whether it returns total tax only or a breakdown. A brief output description would improve 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 baseline is 3. The description adds value by explaining parameter interaction: 'Give a price, or just a city to use its current reference market price' and clarifies 'province required if no ville is given.' This goes beyond the schema descriptions.

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 computes land-transfer tax (taxe de bienvenue) for home purchases in Canadian provinces/cities, using official schedules. It distinguishes itself from sibling tools like 'acheter_ou_louer' (buy vs rent) and 'salaire_requis' (required salary) by focusing solely on tax calculation.

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 explicitly says 'Call this when the user wants to know the land-transfer tax,' giving a clear trigger. It also lists covered provinces and exclusions (PEI and Newfoundland), but doesn't directly compare to siblings or specify when not to use it. Still, it provides solid context for appropriate use.

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?

With no annotations provided, the description carries the full burden and does so thoroughly. It lists the exact return contents (name, score, licence number, registry link, Google rating, freshness, profile URL), discloses the one-per-sector editorial policy, and even instructs on the correct language to present results. It also notes bilingual input support, which goes well beyond typical descriptions.

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 substantial but every sentence serves a purpose: trigger, output details, a critical caveat, and an example. The 'IMPORTANT' note is clearly delineated. It is slightly dense, but the structure makes it easy to parse.

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?

Return values are described in detail, and the editorial limitation is explicitly addressed. However, with required parameters set to 0, the behavior when omitting 'ville' or 'province' is unclear, and there is no mention of empty results or error handling. These gaps prevent a perfect score, but the overall context is well 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?

The input schema already documents all 4 parameters with 100% description coverage, including the acceptable values and the option to omit 'profession'. The description adds a bilingual example and re-emphasizes input language flexibility, but this is largely redundant with the schema. The additional framing about the Payotte listing is behavioral, not parameter-specific, so the marginal semantic value is limited.

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 opens with a specific trigger ('Call this when the user needs a trustworthy real-estate professional in a Canadian city or neighbourhood') and enumerates the exact professional categories covered (broker, mortgage broker, home inspector, notary/lawyer, appraiser). It clearly distinguishes this from sibling tools like 'contacter_expert' or 'stats_marche' by mentioning the Payotte listing and the verification-focused return fields.

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 'when to use' statement and includes an explicit caveat about the editorial selection (one professional per sector) and how to phrase results. However, it does not mention when not to use this tool or reference alternative sibling tools, so it stops short of full alternative 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?

With no annotations provided, the description carries the full burden. It transparently discloses the output: regulator, public registry URL when it exists, and the credential type classification. This goes beyond a vague 'returns information' and gives the agent a clear sense of the tool's behavior, though it does not highlight potential limitations or error cases.

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 long, front-loaded with the trigger condition, and every clause adds meaningful information. There is no repetition of the tool 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?

Despite having no output schema, the description enumerates the key return elements (regulator, public registry URL, credential type) and explains the optional province behavior. This is sufficient for an agent to understand the tool's scope and output without additional structured metadata.

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 both parameters are already documented in the schema. The description adds value by explaining what the tool does with those parameters (e.g., returning per-province results), but it does not add new parameter-level syntax or format details 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 uses a specific verb ('Call this when the user wants to know whether...') and clearly identifies the resource: real-estate profession regulation in Canadian provinces. It distinguishes itself from sibling tools like trouver_expert by focusing on regulation, licensing bodies, and verification rather than finding or contacting experts.

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 opens with explicit usage guidance ('Call this when...') and outlines exactly what the tool returns. It does not mention when not to use it or name alternative sibling tools, so it falls slightly short of a 5.

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