Verified Canadian real-estate pros + housing data: rates, transfer tax, rent-vs-buy, QC assessments.
Scored across 14 tools
Each tool has a clearly distinct purpose and the descriptions include specific 'Call this when' triggers, which helps an agent select correctly. However, there is some overlap in the property-tax and assessment cluster (e.g., taxe_bienvenue_adresse vs. taxe_mutation, and evaluation_adresse vs. estimer_economie) that could cause occasional misselection for broad queries.
All names are in French, lowercase, and snake_case, which is consistent. But the naming mixes verb_noun patterns (e.g., trouver_expert, verifier_titre) with noun phrases (e.g., evaluation_adresse, frais_revision), so the underlying convention is not uniform.
14 tools is well within the typical 3–15 range and each tool covers a distinct facet of Canadian real-estate decision support (market stats, taxes, assessment, experts, regulations). The set feels scoped and every tool earns its place.
The surface covers a broad lifecycle: buy/rent, affordability, market rates, property taxes, assessment values, appeal deadlines/fees, construction risks, and expert finding/verification. Minor gaps exist, such as no direct tool for municipal property tax rates or standalone mortgage payment calculation, but agents can work around these with existing tools.
Call this when the user wonders whether to rent or buy in a Canadian city. Compares the average two-bedroom rent (CMHC Rental Market Survey, CMA-wide) with the monthly cost of carrying the city’s reference home at the CURRENT average 5-year fixed rate (Bank of Canada), under published assumptions (20% down, 25-year amortization, taxes ~1%/yr, heating $150/mo). Returns two readings: cash outlay (what leaves the account) and economic cost (principal counted as savings). Only cities inside a CMHC-covered metro have rent data.
| Name | Required | Description | Default |
|---|---|---|---|
| ville | Yes | City, e.g. "Montréal", "Toronto", "Winnipeg". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (read-only, idempotent, closed-world), and the description goes well beyond them: it names the data sources (CMHC RMS, Bank of Canada), lists the calculation assumptions (20% down, 25-year amortization, ~1%/yr taxes, $150/mo heating), and explains the two distinct output readings. This is rich behavioral disclosure.
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 usage trigger, then data sources, assumptions, return shape, and limitation in dense but non-redundant sentences. Every sentence carries distinct 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 no output schema, the description carries the return-value burden and does so by describing the two readings (cash outlay vs. economic cost) and the coverage limitation. Nothing an agent needs to call or interpret the tool 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% with a single required "ville" parameter, so the schema already documents the input. The description adds nothing syntactic about the parameter, which is the correct 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 specific decision-support purpose (rent vs. buy in a Canadian city) with the exact quantities compared — CMHC two-bedroom rent vs. carrying cost of the reference home. This clearly distinguishes it from data-only siblings like taux_courants and stats_marche.
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?
"Call this when the user wonders whether to rent or buy in a Canadian city" gives explicit triggering context, and the trailing note about CMHC-covered metros implies when the tool will not apply. It stops short of naming a sibling alternative for related questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this ONLY when the user explicitly asks to contact, reach out to, or request a quote/appointment from a Payotte-listed professional. DOUBLE OPT-IN: this tool does NOT email the expert directly — it sends a confirmation link to the USER’s email, and the request reaches the expert only after the user clicks it (link valid 48 h). Tell the user to check their inbox. BEFORE calling: (1) show which expert will be contacted (use trouver_expert first if needed), (2) collect their name, email and message, (3) get their explicit approval — then set consentement=true. Never invent contact details. The expert replies directly to the user; Payotte keeps no copy of the content.
| Name | Required | Description | Default |
|---|---|---|---|
| ville | Yes | City of the expert, e.g. "Montréal". | |
| message | Yes | The user’s request in their own words (need, property, timeline…), 20–2000 characters. | |
| secteur | No | Neighbourhood/sector of the expert (recommended — identifies exactly one expert). | |
| province | No | Province name or code (optional disambiguator). | |
| client_nom | Yes | Full name of the user requesting contact. | |
| profession | Yes | real-estate-broker | mortgage-broker | home-inspector | notary-lawyer | appraiser (French labels accepted). | |
| consentement | Yes | MUST be true, and only after the user explicitly approved sending this request to this specific expert. | |
| client_courriel | Yes | Email address of the user — the expert will reply there. | |
| client_telephone | No | Optional phone number of the user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the non-obvious double opt-in flow: it does NOT email the expert, instead sends a confirmation link to the user (valid 48h), only reaching the expert after the click, and Payotte keeps no copy. This goes well beyond the annotations and covers the key behavioral surprise of the tool.
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 ONLY-when trigger, then the opt-in mechanics, then a compact numbered pre-call checklist. Despite its length, nearly every sentence carries distinct operational information and none is redundant with 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 9-parameter mutation tool with no output schema, the description covers trigger, mechanism, prerequisites, safety constraints, and what the user should expect afterward. It is nearly complete; only field-level edge cases (e.g., validation failures) are left to the schema's own constraints.
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 a baseline of 3 applies, but the description adds real semantics: it explains the ordering of collected inputs, the consentement=true gating rule, and the warning never to invent contact details. It stops short of clarifying field-level formats, which the schema already handles.
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 precise verb+resource (contact a verified Payotte-listed professional) and immediately distinguishes its trigger from siblings by requiring an explicit user request and pointing to trouver_expert as a prerequisite lookup. An agent can tell exactly what this tool does and when it applies 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?
Gives explicit when-to-use (only on explicit user request to contact/request a quote), names the alternative (trouver_expert to select the expert first), and lays out a numbered precondition sequence ending in consentement=true. No usage inference is left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when the user asks how much they could save on property taxes if their assessment went down, or whether contesting is worth the fee. Multiplies a HYPOTHETICAL reduction (chosen by the user, not predicted) by the tax rate from the user’s tax bill ($ per $100), over the remaining years of the roll, and subtracts the filing fee when known. Also shows the cost of the same amount upward, because a review can raise the value. Ask the user for their tax rate: Payotte does not guess municipal rates.
| Name | Required | Description | Default |
|---|---|---|---|
| taux | Yes | Property-tax rate in $ per $100 of assessment, from the user’s tax bill (e.g. 0.75). | |
| baisse | Yes | Hypothetical reduction: in CAD (e.g. 30000) or as a fraction (e.g. 0.08 for 8%). | |
| valeur | Yes | Assessed value on the roll (CAD). | |
| municipalite | No | Quebec municipality (optional but recommended: sets remaining roll years and the fee). | |
| annees_restantes | No | Optional: years of the roll the reduction would cover (1-3). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent, non-destructive profile, so the burden is lighter. The description adds real behavioral value: it discloses the computation method, that it subtracts the filing fee when known, that it also shows the upward cost, and that it will not guess municipal rates.
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 trigger is front-loaded and every sentence carries information, though the parenthetical 'because a review can raise the value' and the closing instruction slightly pad an otherwise efficient passage.
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 reasonably describes what the tool returns (savings and upside cost) and the inputs it depends on. It is complete enough to call correctly, though it does not detail the output structure or units of the returned figures.
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, but the description adds meaning beyond the schema by clarifying that 'baisse' is a hypothetical chosen by the user rather than a predicted value, and that the tax rate must come from the user's tax bill.
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 quantitative job — multiplying a hypothetical assessment reduction by the tax rate over remaining roll years and subtracting the filing fee — which is distinct from siblings like frais_revision or taux_courants. An agent can tell exactly what resource and output this tool produces.
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 states the exact trigger ('when the user asks how much they could save on property taxes if their assessment went down, or whether contesting is worth the fee'), covering both the savings and cost-benefit use cases. It also specifies the prerequisite action of asking the user for their tax rate rather than guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when a homeowner asks about the assessed value of a SPECIFIC address, whether their assessment is too high, or what their home is worth. Reads the OPEN assessment rolls (Quebec: 1,113 municipalities; Nova Scotia; New Brunswick; Winnipeg; Calgary, Edmonton, Lethbridge, Strathcona, Okotoks, Grande Prairie, St. Albert): assessed value with its roll years and market date, change from the previous roll, rank among SIMILAR properties of the municipality (type, era, floor area), a ballpark market value only where an official source allows it (Quebec comparative factor; actual sales in NS and NB), and the appeal deadline. Public figures compared, never an opinion of value. No owner names. Other provinces have no open roll by address.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| adresse | Yes | Civic address, number first, e.g. "9060 boul. Lévesque E" or "1200 rue Saint-Alexandre, app. 305". | |
| province | Yes | Province name or code (QC, NS, NB, AB, MB). | |
| municipalite | Yes | Municipality as named in the roll, e.g. "Laval", "Halifax Regional Municipality", "Calgary", "Winnipeg". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: it discloses that only open rolls are read, that no owner names are returned, that figures are comparisons rather than an opinion of value, and that ballpark market value is emitted only where an official source permits it.
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 trigger sentence, then a dense enumeration of returned data and coverage. Every sentence carries information, though the long municipality list is bulky; still, no wasted 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?
With no output schema, the description carries the full burden and does so: it enumerates the return payload (assessed value, roll years, market date, change from previous roll, rank among similar properties, ballpark market value, appeal deadline) and states the coverage boundaries. An agent knows exactly what to expect.
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 75%, so most parameters are self-documented, but the description adds meaning for the province parameter by enumerating the covered jurisdictions (Quebec, NS, NB, MB, AB cities) and for market value by tying it to the source per jurisdiction. The lang enum is left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (reads open assessment rolls for a single address) and precisely scopes it to homeowner questions about assessed value, over-assessment, or home worth. It clearly distinguishes itself from portfolio/market tools like stats_marche or taxe_bienvenue_adresse by being address-specific.
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?
Explicit trigger condition ("Call this when a homeowner asks about the assessed value of a SPECIFIC address...") plus an exclusions clause ("Other provinces have no open roll by address"). It does not name sibling tools as alternatives, so it stops 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.
Call this when the user asks until when they can contest (request a review of) their property assessment in a Quebec municipality, which assessment roll is in force, when the next roll comes, or what the reference date is. Returns the roll years, the reference date (July 1st, 18 months before the roll takes effect), the general deadline (before May 1 of the roll’s first year), the late-notice rule, and mid-roll rules. Compiled by Payotte from the official Quebec rolls (MAMH open data). For other provinces, pass province (e.g. "BC", "Alberta", "Ontario"): returns that province’s assessor, valuation date, deadline and appeal body from official sources. Tell the user their assessment notice prevails. Does not say whether an assessment is too high.
| Name | Required | Description | Default |
|---|---|---|---|
| province | No | Province code or name (BC, AB, SK, MB, ON, QC, NB, NS, PE, NL). Default: Quebec (then `municipalite` is used). | |
| date_avis | No | Optional: mailing date printed on the assessment notice (YYYY-MM-DD), to apply the 60-day late-notice rule. | |
| municipalite | No | Quebec municipality, e.g. "Drummondville", "Gatineau", "Montréal" (not needed outside Quebec). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read-only, idempotent, non-open-world lookup, so the safety profile is covered. The description then adds real value beyond the annotations: data provenance (Payotte, MAMH open data; official sources for other provinces), the caveat that the assessment notice prevails, and the exact rule set returned.
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 trigger condition is front-loaded in the first sentence, followed by return values, provenance, and scope limits. It is somewhat dense across three sentences, but each clause carries distinct information and none is wasted.
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 fully compensates by enumerating the returned fields (roll years, reference date, general deadline, late-notice and mid-roll rules). For a zero-required-parameter lookup tool this is complete enough for an agent to call and interpret it 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 description coverage is 100%, so all three parameters (`province`, `date_avis`, `municipalite`) are already documented, including the late-notice rule link for `date_avis`. The description reinforces the Quebec default and the province-code behavior but adds little syntax or format detail the schema does not already carry — the expected baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — determining the deadline window to contest a property assessment — and enumerates exactly what it returns (roll years, reference date, general deadline, late-notice rule, mid-roll rules). The closing line 'Does not say whether an assessment is too high' cleanly separates it from valuation/estimation siblings like estimer_economie.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger conditions ('when the user asks until when they can contest...which assessment roll is in force, when the next roll comes'), covers the out-of-Quebec case via `province`, and states a boundary (not for judging whether an assessment is too high). It stops short of naming an alternative sibling tool for that out-of-scope question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FRANCE. Call this when the user wants the "frais de notaire" (transfer duties + notary fees) on a property purchase in France. Same computation as payotte.com/france: departmental duty rate (DGFiP schedule, incl. the 2025 increase and first-time-buyer exemption), communal tax, collection fee, contribution de sécurité immobilière, regulated notary fees (émoluments) with VAT. type "ancien" (default, needs a département) or "neuf" (new build, reduced rate). Disbursements are not regulated and not included.
| Name | Required | Description | Default |
|---|---|---|---|
| prix | Yes | Prix d’achat en euros. | |
| type | No | ancien (défaut) ou neuf. | |
| departement | No | Code (« 33 », « 2A ») ou nom (« Gironde ») du département ; une ville couverte marche aussi. | |
| primoAccedant | No | Ancien : premier achat de résidence principale (taux sans la hausse de 2025, si le département l’a votée). | |
| tvaMentionnee | No | Neuf : TVA mentionnée distinctement dans l’acte (assiette hors TVA). |
Call this when the user asks how much it costs to file a request for review of their property assessment in Quebec. Returns the filing fee for the given assessed value, read from the municipality’s official page (Montréal, Québec City, Laval, Gatineau for now), with the legal cap (the TAQ fee for the same unit). Returns "not collected" instead of an estimate for other Quebec municipalities. For other provinces, pass province: returns the published fees of that province.
| Name | Required | Description | Default |
|---|---|---|---|
| valeur | No | Assessed value on the roll in CAD (the value on the notice, not the market price). | |
| province | No | Optional province code or name; default Quebec. | |
| municipalite | No | Quebec municipality, e.g. "Montréal", "Laval". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile; the description adds the substantive behavior: the fee is read from the municipality's official page, coverage is limited to Montréal, Québec City, Laval and Gatineau for now, the legal TAQ cap is included, and other Quebec municipalities return 'not collected' rather than an estimate. This is exactly the operational context annotations cannot convey.
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, front-loaded with the trigger, and each one carries distinct information (when to call, what is returned and from where, fallback behavior, province routing). No filler or repetition.
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 does the work of explaining the return value ('not collected', published provincial fees, TAQ cap) and coverage limits. It is nearly complete, though it never states behavior when all optional parameters are omitted or what happens for a Quebec municipality outside the four supported ones.
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, but the description goes further by explaining that `province` should be passed for non-Quebec jurisdictions and that `valeur` is the assessed roll value. It adds real usage semantics on top of 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 states a precise verb and resource (returns the filing fee for a request for review of a property assessment), plus the geographic scope (Quebec, with four named municipalities). It does not explicitly distinguish itself from close siblings like fenetre_revision or taxe_mutation, so an agent must still 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?
It gives an explicit trigger ('Call this when the user asks how much it costs to file a request for review') and routes the agent to the province parameter for non-Quebec cases. It never names a sibling tool or states when to prefer an alternative, so the routing guidance stops just short of the top level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when someone asks what to check in a house given its age, or before an inspection. Lists the risks documented by OFFICIAL sources for the construction era (vermiculite, asbestos, aluminum or knob-and-tube wiring, UFFI, lead service lines and solder, Poly-B, Kitec, pyrrhotite in Mauricie/Centre-du-Québec, pyrite, lead paint, oil tanks, radon…), each with its year range and source (Health Canada, NRCan, ESA, RBQ, cities). Year taken from the open roll when an address is given, or from "annee". A list of what to verify, never a diagnosis.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| annee | No | Construction year, if no address or if the roll lacks it. | |
| adresse | No | ||
| province | Yes | ||
| municipalite | No |
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 genuine context beyond them: it discloses the year-resolution fallback ('taken from the open roll when an address is given, or from annee') and clarifies output nature ('a list of what to verify, never a diagnosis').
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 trigger, then the risk inventory, then the resolution mechanics. It is dense but every clause carries information; the enumerated risk list is long but justifies its space as the tool's payload.
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 tool with no output schema, the description conveys what is returned (risks, each with a year range and source) and how the year is resolved. It stops short of explaining municipalite's effect and return format details, but nothing critical to invoking 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?
Schema coverage is only 20%, so the description must compensate, and it does for the load-bearing params: it explains how adresse and annee interact for resolving the year, and province is required. The roles of municipalite and lang are not spelled out in the description, leaving a small gap.
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: it lists risks documented by official sources for a home's construction era, with named examples. It is unmistakably distinct from the finance/inspection siblings (frais, taxe, taux, stats), so an agent can route to it without opening a 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?
Explicit trigger conditions are given: 'when someone asks what to check in a house given its age, or before an inspection.' No sibling alternatives are named, but the use context is clear enough for confident selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when the user asks what income is needed to buy a home in a Canadian city. Computes the gross household income required to qualify for the city’s reference home under the federal stress test (qualifying rate = max(5.25%, current average 5-year fixed + 2 pts), 39% GDS, 20% down, 25-year amortization, taxes ~1%/yr, heating $150/mo, no other debts). Same published methodology as payotte.com/salaire-pour-acheter-une-maison-canada. A theoretical qualification threshold, not a loan offer.
| Name | Required | Description | Default |
|---|---|---|---|
| prix | No | Optional price in CAD to test instead of the city’s reference price. | |
| ville | Yes | City, e.g. "Montréal", "Vancouver", "Halifax". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds substantial calculation context: the stress test rate formula, GDS ratio, down payment, amortization, tax and heating assumptions, and an explicit disclaimer that it is not a loan offer. This is rich behavioral disclosure beyond structured data.
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 front-loaded with the usage trigger, followed by the computation method, methodology source, and disclaimer. Every sentence adds necessary context, and there is no filler despite the technical detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description clearly states that the tool computes a gross household income figure and describes the assumptions behind it. It could go slightly further by specifying the exact return shape or units, but it is otherwise complete for the agent's needs.
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 implies that ville selects a city reference home and prix optionally overrides it, but this largely restates the schema descriptions rather than adding new semantic detail.
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 computational resource: the gross household income required to buy a home in a Canadian city. It clearly distinguishes this from sibling tools by output type, but it never explicitly names an alternative or contrast, so it falls short of the explicit sibling differentiation expected for 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?
It gives a clear triggering condition: call when the user asks what income is needed to buy a home in a Canadian city. No when-not guidance or alternative tool recommendations are provided, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this for current housing-market figures in a Canadian city: reference price (MLS HPI benchmark or median), year-over-year change, sales volume, months of inventory, days on market, 5-year growth. Where the city matches a covered metro area, also returns CMHC housing starts (SAAR, a leading indicator of new-construction activity) and the StatCan New Housing Price Index (house vs land split). Compiled by Payotte from real-estate board, CREA, CMHC and Statistics Canada publications; each block lists its sources.
| Name | Required | Description | Default |
|---|---|---|---|
| ville | Yes | City, e.g. "Montréal", "Ottawa", "Vancouver". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world. Beyond that, the description discloses provenance (real-estate board, CREA, CMHC, StatCan) and the conditional return behavior for metro-matched cities, which an agent needs to interpret the response. It does not state data freshness/currency beyond 'current', which is the main remaining gap.
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 dense sentences, front-loaded with the trigger ('Call this for...') followed by the payload. The metric list is long but each item earns its place by telling the agent what data comes back; the sources sentence is slightly trailing but useful.
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 returns and does so adequately, including the conditional CMHC/StatCan blocks. It omits units/currency and data-recency caveats, which an agent might still need for correct interpretation.
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?
Only one parameter (ville), and the schema already documents it at 100% coverage with matching city examples. The description adds no format, normalization, or matching-rule detail (e.g. how a city name is resolved to a covered metro), so the schema does the heavy lifting — baseline 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 states a specific verb+resource ('current housing-market figures in a Canadian city') and enumerates the exact metrics returned (MLS HPI benchmark or median, YoY change, sales volume, months of inventory, DOM, 5-year growth). It is unambiguous against siblings like taux_courants or taxe_mutation, which cover different domains.
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?
'Call this for...' gives a clear triggering context, and the conditional clause tells the agent when extra CMHC/StatCan blocks appear (when the city matches a covered metro). No explicit exclusions or named alternatives are given, so it stops 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.
FRANCE. Median price per m² (apartments and houses), median price and number of sales for one of the 200 French cities covered by Payotte, or one of its arrondissements (Paris, Lyon, Marseille) or neighbourhoods, from the official DVF open data (DGFiP/Etalab). Latest full year and the year before. Cells under 10 sales are never published.
| Name | Required | Description | Default |
|---|---|---|---|
| ville | Yes | Ville, p. ex. « Bordeaux », « Lyon ». | |
| quartier | No | Facultatif : nom d’un quartier officiel de la ville. | |
| arrondissement | No | Facultatif : « 15e », « 75015 »… (Paris, Lyon, Marseille). |
Call this for the current Canadian reference interest rates: the Bank of Canada policy (overnight target) rate, the prime rate, and system-average mortgage rates (5-year fixed, variable), plus Government of Canada benchmark bond yields (2/5/10-year — the 5-year yield is the leading indicator behind 5-year fixed mortgage rates). Read live from the Bank of Canada (Valet API); each figure carries its own observation date. Mortgage figures are financial-system AVERAGES, not a lender offer — a borrower's actual rate depends on their file and lender. Source: Bank of Canada.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds real value beyond them: the upstream source (Bank of Canada Valet API), that figures are read live, that each carries its own observation date, and the important caveat that mortgage numbers are system AVERAGES rather than a lender offer.
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 trigger and the headline list of rates, then layered with source, date semantics, and the averages caveat. It is on the longer side for a single paragraph, but each clause carries distinct information an agent would otherwise have to guess.
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 explaining what comes back, and it does so thoroughly (the specific rate types plus per-figure observation dates). Source provenance and the mortgage-average caveat round out everything needed to call and interpret it.
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 takes zero parameters, so the baseline of 4 applies. The description instead spends its budget describing the returned figures, which is the useful information for a no-input tool.
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 resource (current Canadian reference interest rates) and enumerates exactly which figures it returns: BoC policy rate, prime rate, system-average mortgage rates, and GoC benchmark bond yields. An agent can distinguish this from 'stats_marche' or other siblings without reading 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?
Opens with an explicit trigger ('Call this for the current Canadian reference interest rates'), giving clear context for when it applies. It does not, however, name an alternative sibling or state when-not to use it, so routing against 'stats_marche' 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.
Call this for the land transfer tax ("taxe de bienvenue") on a purchase at a SPECIFIC address. In Quebec (Act respecting duties on transfers of immovables, s. 2 and 1.1) and New Brunswick (s. 2(1.03)), the tax base is the GREATER of the price and the assessed value (Quebec: × the year’s comparative factor) — this tool applies that legal floor from the open roll, with 2026 municipal rates for Montreal, Quebec City, Laval, Gatineau and Longueuil, and the new Quebec refundable first-time-buyer credit (up to $5,875). Elsewhere the tax is computed on the price alone. The municipality’s bill and the notary/lawyer confirm the exact amount.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| prix | Yes | Purchase price in CAD. | |
| adresse | No | ||
| province | Yes | ||
| municipalite | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe, read-only, idempotent computation, so the bar is lower. The description adds real value beyond them: the legal floor (greater of price and assessed value), the Quebec/NB vs. elsewhere computation model, the covered municipalities, and the disclaimer that the municipality's bill and notary confirm the exact amount, signalling this is an 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?
The purpose is front-loaded in the first sentence, followed by the supporting legal detail. It is dense and leans on statutory citations that an agent does not need, but every sentence still contributes to understanding the calculation or its limits.
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 still conveys the computation basis and the caveat that the authoritative amount comes from the municipality/notary. Combined with annotations covering safety, an agent has enough to invoke it correctly, though it never describes the response shape or whether a breakdown is returned.
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 only 20% (only prix is documented), so the description must compensate. It does so partially: province is tied to the legal regime (Quebec/NB vs. elsewhere), municipalite to the 2026 municipal rates for named cities, and adresse to the open roll/assessed value. The lang enum and the accepted province values are never explained.
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 first sentence states a specific verb and resource: compute the land transfer tax ("taxe de bienvenue") for a purchase at a SPECIFIC address. The "SPECIFIC address" scope implies the distinction from the generic sibling taxe_mutation, but it never names that alternative explicitly, so the differentiation is left to inference.
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?
"Call this for the land transfer tax on a purchase at a SPECIFIC address" gives a clear triggering condition. However, it never says when NOT to use it (e.g. vs. taxe_mutation for a general estimate) nor names any alternative, so routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when the user wants to know the land-transfer tax ("taxe de bienvenue" in Quebec) on a home purchase in a Canadian city or province. Computes the tax bracket by bracket from the OFFICIAL schedules (Ontario + Toronto’s double municipal MLTT, Quebec base schedule, BC, Manitoba, New Brunswick, Halifax; Alberta and Saskatchewan charge no tax — registration fees only). Give a price, or just a city to use its current reference market price. Includes first-time-buyer rebates. Not covered: PEI and Newfoundland.
| Name | Required | Description | Default |
|---|---|---|---|
| prix | No | Purchase price in CAD. Omit with a ville to use the city’s reference market price. | |
| ville | No | City, e.g. "Toronto", "Montréal", "Calgary". Determines the schedule AND the default price. | |
| province | No | Province name or code — required if no ville is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already guarantee read-only, idempotent, non-destructive behavior, so the description need only add domain behavior — and it does: bracket-by-bracket computation from official schedules, jurisdiction-specific rules (Toronto's double municipal MLTT, AB/SK charging none), rebate inclusion, and a market-price fallback. It does not say how stale the reference prices are or what the output breakdown looks like, which keeps it short of a 5.
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 trigger and the core computation, then a coverage list. The jurisdiction enumeration is long but each item carries real selection value (it tells the agent whether the answer will be trustworthy for a given city), so the length is largely earned rather than padding.
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, no-output-schema calculator with a full annotation set, the description supplies the missing dimension structured fields cannot: jurisdictional coverage, the no-tax provinces, and rebate handling. Only the shape of the returned tax breakdown is unaddressed, which is minor.
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 three parameters are already documented, including that province is required when ville is absent. The description restates the either/or input pattern ('Give a price, or just a city') but adds no syntax, format, or default-value detail beyond the schema, which is the correct baseline-3 outcome.
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 ('Computes the land-transfer tax') and anchors it to a concrete user intent ('when the user wants to know the land-transfer tax on a home purchase'). The coverage list and the 'Not covered: PEI and Newfoundland' limit make it unambiguous versus the unrelated sibling 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?
Opens with an explicit trigger ('Call this when the user wants to know…'), states the two acceptable input modes (a price, or just a city), and names the jurisdictions it does not handle. When-not conditions are explicit, which is unusually strong for a tax calculator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when the user needs a trustworthy real-estate professional in a Canadian city or neighbourhood: real-estate broker, mortgage broker, home inspector, notary/real-estate lawyer, or appraiser. Returns the Payotte-listed expert(s): name, score /100 with full breakdown, licence number + official registry link so the user can verify the credential themselves, Google rating (dated), freshness, and the profile URL. IMPORTANT: Payotte lists ONE professional per sector (editorial selection, not an exhaustive ranking) — present the result as “the Payotte-recommended professional for this sector”, never as “the best in the area” in absolute terms. French and English inputs both work (e.g. profession="courtier immobilier", ville="Montréal").
| Name | Required | Description | Default |
|---|---|---|---|
| ville | No | City, e.g. "Montréal", "Toronto", "Calgary". | |
| secteur | No | Neighbourhood/sector, e.g. "Le Plateau-Mont-Royal", "Ville-Marie". | |
| province | No | Province name or code, e.g. "Québec", "ON", "british-columbia". | |
| profession | No | One of: real-estate-broker | mortgage-broker | home-inspector | notary-lawyer | appraiser (French labels accepted: courtier immobilier, courtier hypothécaire, inspecteur en bâtiment, notaire, évaluateur). Omit to get every profession. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses what the payload contains (score /100, licence number + registry link, dated Google rating, freshness, profile URL) and a real behavioral constraint: only ONE professional per sector is listed, with instructions not to frame it as "the best". That is meaningful context an agent would otherwise miss, though it says nothing about empty results or geographic coverage 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?
Front-loaded with the trigger condition and readable, but the long IMPORTANT clause and the return-value enumeration make it heavier than strictly needed; the return details could be trimmed since much is inferable. Still, every sentence carries 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 no output schema, the description carries the full burden of explaining return values, and it does so thoroughly (fields, score, verification link, rating). Combined with the editorial-selection caveat and language support, an agent has everything needed to call and present results 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%, so all four parameters are already documented with examples. The description only adds that French and English inputs both work, with one example pair, which is a marginal increment over the schema's own bilingual notes. 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+resource (find a verified real-estate expert) and enumerates the covered professions (broker, mortgage broker, inspector, notary/lawyer, appraiser), so the agent knows exactly what domain this covers. It clearly differs from sibling tools like taux_courants or taxe_mutation.
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?
"Call this when the user needs a trustworthy real-estate professional in a Canadian city or neighbourhood" gives a clear triggering condition. However, it never mentions the sibling contacter_expert (presumably for reaching out after finding one) or verifier_titre, so the agent gets no explicit routing guidance among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FRANCE. Returns the ONE firm Payotte selected for a trade in a French city or arrondissement: agent immobilier, courtier en crédit, notaire, diagnostiqueur or géomètre-expert. Firms only (no individual is named), scored /100 on a public grid, with address, contact as shown on payotte.com/france and the profile link. Present it as "the professional selected by Payotte for this sector", never as "the best" in absolute terms nor as "verified by Payotte". Returns caseVacante when no firm is selected.
| Name | Required | Description | Default |
|---|---|---|---|
| ville | Yes | Ville, p. ex. « Nantes ». | |
| metier | Yes | Métier : agent-immobilier, courtier-credit, notaire, diagnostiqueur, geometre-expert. | |
| secteur | No | Arrondissement pour Paris, Lyon, Marseille (« 11e », « 75011 ») ; inutile ailleurs. |
Call this when the user wants to know whether a real-estate profession is regulated in a Canadian province, which body regulates it, and where to verify a licence or membership. Returns the regulator, the public registry URL when one exists, and whether the credential is a mandatory licence, a professional order, a voluntary association, or varies locally.
| Name | Required | Description | Default |
|---|---|---|---|
| province | No | Province name or code. Omit to get every province for that profession. | |
| profession | Yes | real-estate-broker | mortgage-broker | home-inspector | notary-lawyer | appraiser (French labels accepted). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds useful context beyond that: it enumerates what the call returns (regulator, public registry URL when one exists, and the credential classification), which matters because no output schema exists. It could still say more about the four credential categories or missing-data behavior.
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 waste: the first is the trigger condition, the second is the return contract. Front-loaded with the when-to-call clause, exactly what an agent scans first.
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 compensates by describing the returned fields (regulator, registry URL, credential type) and the conditional nature of the URL. Combined with read-only annotations and fully documented parameters, an agent has everything needed to call and interpret this 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 description coverage is 100%: the schema already documents that 'province' may be omitted to broaden results and lists the accepted 'profession' values. The description adds no format, casing, or fallback guidance for either parameter, 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 (verify) and resource (a professional title / its regulator), plus the exact question it answers: is this profession regulated, by which body, and where to verify a licence. None of the sibling tools (taux_courants, salaire_requis, trouver_expert, etc.) overlap with this regulatory-verification purpose, so an agent can select it unambiguously.
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 opening clause 'Call this when the user wants to know whether a real-estate profession is regulated...' gives an explicit trigger condition an agent can match against user intent. It does not name exclusions or contrasting siblings, but the sibling set is in clearly different domains, so no real ambiguity remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FRANCE. For a trade (agent immobilier, courtier en crédit, notaire, diagnostiqueur, géomètre-expert), tells which official title or registry applies (carte T from the CCI, ORIAS, nomination order, certification body, Ordre des géomètres-experts), which identifier to ask for, and where the reader can check it themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| metier | Yes | Métier : agent-immobilier, courtier-credit, notaire, diagnostiqueur, geometre-expert. |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
frais_notaire_frstats_marche_frtrouver_professionnel_frverifier_titre_frevaluation_adresserisques_annee_constructiontaxe_bienvenue_adressefenetre_revision3 fields changedInput schema / properties / municipalite / descriptionPrevious value: -"Quebec municipality, e.g. \"Drummondville\", \"Gatineau\", \"Montréal\"."New value: +"Quebec municipality, e.g. \"Drummondville\", \"Gatineau\", \"Montréal\" (not needed outside Quebec)."Input schema / properties / province / descriptionPrevious value: -"Optional; only Quebec is covered."New value: +"Province code or name (BC, AB, SK, MB, ON, QC, NB, NS, PE, NL). Default: Quebec (then `municipalite` is used)."Input schema / requiredPrevious value: -[
- "municipalite"
-]New value: +[]frais_revision2 fields changedInput schema / properties / provinceAdded value: +{
+ "description": "Optional province code or name; default Quebec.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "municipalite",
- "valeur"
-]New value: +[]estimer_economiefenetre_revisionfrais_revisionacheter_ou_louersalaire_requistaxe_mutationtaux_courantscontacter_expertstats_marchetrouver_expertverifier_titreGet matched with a top-rated, review-verified real estate agent in the US or Canada.
Cited, receipt-backed US home-buying data & calculators — education-only, every number sourced.
Real Australian lender serviceability, plus repayments, borrowing power and stamp duty.
Québec land intelligence: municipal decisions, zoning, assessment roll, registry, permits.
Add one secure layer between your agents and this server.
