Estimation DVF indicative, frais de notaire et rendement locatif, en lecture seule.
Scored across 6 tools
Each tool has a clearly distinct purpose: content search, token identity, operator identity, notary fee simulation, rental yield simulation, and service status. There is no overlap or ambiguity between them.
Tool names follow a consistent style of lowercase with underscores and are descriptive. However, the pattern is mixed: some begin with verbs (chercher, simuler) while others begin with nouns (identite, statut), which is a minor inconsistency but still readable.
With 6 tools, the server is well-scoped for its purpose of providing information and simulations for ScoreImmobilier.fr. Each tool earns its place and the count is within the ideal 3-15 range.
The tool set covers the core functionalities: content search, identity verification, cost simulations, and service status. Minor gaps exist (e.g., no dedicated tool for property tax simulation), but these are adequately handled within the rental yield tool, so agents can work around them.
Annule une action preparee non confirmee (scope leads.write).
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive. The description adds the precondition that the action must be 'preparee non confirmee', but it does not disclose side effects (e.g., whether the action is deleted or marked as cancelled), nor does it mention any authorization or state change details beyond the 'leads.write' scope.
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, succinct sentence that front-loads the core purpose. It contains no filler and is appropriately concise for a simple tool.
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 low-complexity tool with one parameter and no output schema, the description covers the essential purpose and precondition. It does not mention return values or error handling, but given the simplicity of the operation, this is an acceptable level of 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?
The schema has a single integer parameter 'action_id' with no description (0% schema coverage). The description implies that the tool cancels an action, so 'action_id' likely refers to the identifier of the action to cancel, but it does not explicitly state this or clarify how to obtain the ID. The description partially compensates but leaves some ambiguity.
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 verb 'Annule' (cancel) and the specific resource 'action preparee non confirmee' (prepared unconfirmed action). It distinguishes this tool from the sibling 'confirmer_action' by focusing on cancellation of unconfirmed actions, making its purpose 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?
The description specifies the condition 'non confirmee', implying it should be used only for prepared actions that haven't been confirmed yet. It provides a clear usage context but does not explicitly contrast with alternatives like 'confirmer_action' or mention exclusions beyond that condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche dans l'index public des pages de ScoreImmobilier.fr (estimation DVF, guides, fiscalite immobiliere).
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | ||
| requete | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the search is against the 'index public', which is useful scoping context, but it does not disclose behavior such as matching logic, result ordering, pagination, or response format.
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 focused sentence with no filler. It front-loads the core action and resource, and every word contributes useful 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 two-parameter search tool with safety annotations, the description gives the basic scope. However, without an output schema it does not clarify expected return values, and the unexplained 'limite' parameter leaves a meaningful gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. 'requete' is inferable from the search context, but 'limite' is not explained in either the schema or the description, leaving its semantics unclear.
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 a specific action ('Recherche') and resource ('index public des pages de ScoreImmobilier.fr'), and enumerates the content domains covered. It is easily distinguished from the sibling simulation/status 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 implies when to use the tool: whenever the agent needs to search public ScoreImmobilier.fr content. However, it gives no explicit exclusions or comparisons to the sibling tools such as simuler_frais_notaire or simuler_rendement_locatif.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEUXIEME etape : execute une action preparee (ex. demande de rappel). A n'appeler QU'APRES confirmation explicite du visiteur dans la conversation. Idempotent par action_id, expiree au bout de 10 minutes. Scope requis: leads.write.
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses idempotency per action_id, a 10-minute expiration, and the required scope 'leads.write'. It also implies it is a mutating operation (executes an action). These are valuable behavioral traits that an agent needs to know, and they are not contradicted by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the critical 'DEUXIEME etape' context. Each clause delivers distinct information: purpose, usage condition, idempotency, expiry, and scope. There is no wasted wording, and the structure makes the key constraints immediately visible.
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 tool with one parameter, the description covers the essential context: purpose, prerequisite condition, idempotency, expiration, and required scope. There is no output schema, but the description does not need to explain return values per rules. The only minor gap is the lack of explanation about obtaining action_id, but this is inferable from the 'second step' context and does not impair correct usage.
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 schema description coverage is 0%, so the description must compensate for the undocumented action_id parameter. It mentions that the tool is idempotent by action_id, which implies action_id is the identifier, but it does not explain what action_id represents, where it comes from (e.g., a previous proposal step), or its format. The basic identification role is clear, but the semantic link to a prior step is missing.
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 executes a prepared action (e.g., a call reminder request) and is the second step in a process. It distinguishes itself from siblings by indicating it is the execution step versus the proposal (proposer_demande_rappel) or cancellation (annuler_action). However, it does not explicitly name the sibling or the precise action type it handles, so it falls short of a perfect clarity score.
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 an explicit conditional: 'A n'appeler QU'APRES confirmation explicite du visiteur dans la conversation' – it must only be called after explicit visitor confirmation. It also indicates it is the second step, implying a prerequisite from a proposal tool. This is strong usage guidance that prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renvoie les claims du jeton OAuth fourni (sub, scope, audience, expiration) — permet a un client de verifier son autorisation. Sans jeton : indique comment en obtenir un.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only and non-destructive. The description adds useful behavioral context beyond that: it lists the returned claims and explains the no-token fallback behavior. It does not disclose error handling for invalid/expired tokens, but the annotations lower the burden.
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 compact, front-loaded with the core action, and every part adds value: what it returns, why it is useful, and what happens without a token. There is no filler or repetition of schema/annotation data.
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 with no output schema, the description covers the main needs: the returned claims are enumerated, and the no-token case is addressed. It could add how the token is supplied or what invalid-token responses look like, but these are minor gaps.
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 has zero parameters, so the description does not need to explain parameter behavior. The phrase 'jeton OAuth fourni' implies the token comes from the request context rather than a parameter, which is consistent with the empty schema. Baseline 4 applies for a zero-parameter 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?
The description clearly states a specific verb and resource: it returns the claims of the provided OAuth token and lists the key fields (sub, scope, audience, expiration). It is distinct from sibling tools by its explicit focus on OAuth token claims, though it does not explicitly contrast itself with identite_operateur.
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 a clear use case: allowing a client to verify its authorization, and it explains the behavior when no token is present (indicates how to obtain one). It does not explicitly mention when not to use it or name alternatives, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identite publique de l'editeur du site (TENDIL COURTAGE, SIREN, ORIAS) — utile pour verifier qu'il ne s'agit pas d'un site frauduleux.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the data is 'public' but does not disclose additional behavioral traits such as authentication needs, rate limits, or response format. It is consistent with annotations and adds minimal behavioral 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?
The description is a single sentence that front-loads the core subject ('Identite publique') and then adds purpose. It contains no filler or redundancy, making it highly concise and well-structured.
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 lookup tool with no parameters and no output schema, the description adequately conveys what data is returned and why it is useful. It could be slightly more explicit about the output format, but the provided details are sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully covers the inputs (trivially). The baseline is 4 for 0-parameter tools, and the description does not need to add parameter information. It does not provide any input-related detail, which 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 clearly identifies the resource (the site publisher's public identity) and lists specific data fields (TENDIL COURTAGE, SIREN, ORIAS). It distinguishes itself from sibling tools by topic, but it lacks an explicit action verb like 'returns' or 'provides', which is a minor deduction.
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 a clear use case: verifying that the site is not fraudulent. It implies when to use the tool, but it does not explicitly mention alternatives or when not to use it. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste les actions preparees recentes pour le jeton courant (scope leads.read).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the scope requirement but doesn't elaborate on what 'actions preparees' means, whether results are paginated, or if any state changes occur. Since annotations carry the main safety info, this is acceptable 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?
The description is a single, concise sentence that front-loads the primary action (list) and resource (prepared actions). No filler or redundancy. It earns a top score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool with no output schema, the description is sufficiently complete. It specifies the scope and the resource. It could mention whether results are ordered or paginated, but these are minor gaps for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the guidelines. The description doesn't need to add parameter details since none exist. It correctly avoids mentioning any, which 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 clearly states it lists recent prepared actions for the current token, with an explicit scope (leads.read). It distinguishes from siblings like annuler_action and confirmer_action by being a list operation, though it doesn't name them directly. The verb 'Lister' plus the resource 'actions preparees' is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to view prepared actions) but provides no explicit guidance on when to prefer this over alternatives. There's no mention of when not to use it or which sibling to choose for other scenarios. However, for a list action, the context is fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PREMIERE etape d'une ecriture : prepare une demande de rappel (email + consentement explicite OBLIGATOIRES). Retourne un action_id a confirmer par l'utilisateur. Si email ou consentement manquent, retourne une elicitation (question a relayer au visiteur). Scope requis: leads.write.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| Yes | |||
| projet | No | ||
| consent | Yes | accord explicite du visiteur (true requis) | |
| message | No | message du visiteur, sans donnees sensibles | |
| telephone | No | ||
| type_projet | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations that only say readOnly=false, destructive=false, the description carries the full burden of behavioral disclosure. It reveals mandatory email and explicit consent, the two-phase confirmation pattern, the elicitation fallback, and the required leads.write scope. 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 compact and front-loaded, covering purpose, requirements, return value, fallback behavior, and scope in three short sentences. Every sentence adds operational value with 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 tool with no output schema and uninformative annotations, the description is unusually complete: mandatory inputs, return value, elicitation behavior, and required scope are all present. It stops just short of explicitly naming the confirmation sibling and leaves some optional field semantics to the schema.
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 only 29%, so the description needed to compensate. It adds meaning for email and consent by marking them mandatory and explaining the missing-field elicitation, but it does not clarify optional parameters like name, projet, telephone, or type_projet beyond what the schema already shows.
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 action: 'prepare une demande de rappel' and identifies it as the 'PREMIERE etape' of a write flow. The returned action_id 'a confirmer par l'utilisateur' distinguishes it from confirmation and cancellation siblings.
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 clear context: this is the first step, and the returned action_id still needs user confirmation. It implies the next step in the workflow but does not explicitly name confirmer_action or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estime les frais de notaire (droits de mutation, emoluments, formalites) pour un achat ancien ou neuf. Estimation pedagogique.
| Name | Required | Description | Default |
|---|---|---|---|
| prix | Yes | ||
| type_bien | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool readOnly and non-destructive. The description adds behavioral context beyond that by calling the estimate 'pedagogique', signalling that it is approximate/indicative rather than official, and by listing which cost components 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?
One sentence carries the verb, resource, component list, scope, and caveat with no filler. The key action and object are front-loaded, and the pedagogical caveat is placed at the end.
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 two-parameter, read-only estimator, the description is complete: it names the target, scope, included components, and the approximate nature of the result. The absence of an output schema is not a blocker because the return shape is obvious from the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps type_bien to 'ancien ou neuf' and implies that prix is the purchase price used for the estimate, but it never explicitly defines prix or its unit/currency, leaving some inference to the agent.
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 the specific verb 'Estime' and names the resource 'frais de notaire', then enumerates the components (droits de mutation, emoluments, formalites) and scopes the tool to 'un achat ancien ou neuf'. This makes it immediately distinguishable from the sibling simuler_rendement_locatif, which estimates rental yield.
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 clearly states the intended context: notary-fee estimation for old or new purchases. It does not explicitly name exclusion conditions or route to alternatives, so it falls short of a full when/when-not explanation, but the use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcule un rendement locatif brut et net (loyer, charges, taxe fonciere, frais de notaire, travaux). Pedagogique : vacance et fiscalite non incluses.
| Name | Required | Description | Default |
|---|---|---|---|
| travaux | No | ||
| prix_achat | Yes | ||
| loyer_mensuel | Yes | ||
| taxe_fonciere | No | ||
| charges_annuelles | No | ||
| frais_notaire_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the important limitation that vacancy and taxation are not included ('vacance et fiscalite non incluses'), which is valuable behavioral context beyond annotations. It does not mention output format or assumptions, but the core behavior is disclosed.
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, front-loaded with the purpose, and the pedagogical note is appended efficiently. 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?
The description does not describe the return value or structure. It says it calculates gross and net yield, but an agent may not know if it returns a number, a pair, or an object with keys like 'brut' and 'net'. With no output schema, this ambiguity is a gap. The description also lacks details on calculation assumptions, but the pedagogical disclaimer helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the inputs (loyer, charges, taxe fonciere, frais de notaire, travaux) but does not clarify units or meaning beyond the parameter names. For example, 'frais_notaire_pct' is not stated to be a percentage, and 'charges_annuelles' is not specified as annual. This leaves ambiguity for the agent.
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?
Description states a specific verb 'Calcule' and a specific resource 'rendement locatif brut et net', listing the inputs. It clearly distinguishes from sibling tools like simuler_frais_notaire by focusing on overall rental yield rather than just notary fees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for rental yield calculation but does not explicitly mention alternatives or when not to use it. It lacks guidance on choosing between this tool and simuler_frais_notaire or other siblings, though the pedagogical note hints at a simplified scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ce que ScoreImmobilier.fr fait et ne fait pas (pas d'agence, pas de vente, pas de carte Hoguet) — a utiliser pour toute question de confiance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the bar. The description adds content-level context by disclosing what information the tool provides (scope, exclusions, limitations). It aligns with the read-only, non-destructive annotations and adds value by specifying the trust-related content scope. No contradiction.
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, tightly packed sentence that front-loads the core function (what the platform does/doesn't do) before the usage trigger. Every clause earns its place — scope, key exclusions, and usage guidance — with zero filler or redundancy.
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 informational tool with no output schema, the description covers the essentials: purpose and when to use it. The return format is not specified, but for a status/trust informational tool this is a minor gap; the description is largely sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. With an empty input schema, there is nothing for the description to clarify — no parameter documentation burden exists. The description appropriately focuses on purpose and usage instead.
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: it explains what ScoreImmobilier.fr does and does not do, with specific exclusions (no agency, no sales, no Hoguet card). This differentiates it from siblings that search content, simulate fees, or identify the operator. A slight deduction because no explicit verb like 'explains' or 'describes' is stated, though the intent 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?
The description provides explicit usage context — 'a utiliser pour toute question de confiance' (to use for any question of trust) — which tells an agent when to invoke it. It doesn't name alternatives or explicitly state when NOT to use it, but the trust-question trigger is a clear and distinct use case against the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
annuler_actionconfirmer_actionlister_actionsproposer_demande_rappelidentite_jetonchercher_contenuidentite_operateursimuler_frais_notairesimuler_rendement_locatifstatut_servicesDonnées immobilières DVF France : transactions, comparables GPS et statistiques de marché.
Prix au m² communal, synthèse de marché et formalité d'urbanisme, sur données publiques françaises.
Instant pricing for French land-registry documents (etat hypothecaire, deeds). Read-only, no auth.
Données immobilières officielles françaises (DVF+, cadastre, DPE, risques, urbanisme) via MCP.
Add one secure layer between your agents and this server.
