SCPI Select

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context — that entries are dated and sourced to the manager's press release or bulletin — but says nothing about ordering, completeness, or what an empty result means.

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?

It is a single front-loaded sentence beginning with the verb and containing no filler. The chain of comma-joined qualifiers ('datées et sourcées au communiqué ou au bulletin du gestionnaire') makes it slightly dense to scan, but nothing 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?

For a two-parameter, zero-required read tool with rich annotations and no output schema, the description covers what is returned and where it comes from. Only minor points remain open, such as whether the day window is measured against the announcement date and how results are ordered.

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

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

Schema description coverage is 100% and both parameters are documented there, including the 90-day default and 730-day maximum. The description only restates that the SCPI filter is optional, adding essentially no meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Liste') plus a well-scoped resource ('acquisitions d'immeubles annoncées par les SCPI') and adds the provenance of the data. It is clearly distinct from fiche_scpi, comparer_scpi or mouvements_prix by virtue of being about property acquisitions, but it never names a sibling to route against.

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?

'éventuellement pour une seule SCPI' implies that the tool can be used broadly or narrowed to one manager, but there is no explicit when-to-use versus when-to-prefer-a-sibling guidance and no exclusions. Usage has to be inferred from the phrasing.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered structurally. The description adds the substantive behavioral fact that comparison is performed 'sur les mêmes chiffres' across a fixed metric set, which tells the agent what it will get back. It does not cover what happens with unrecognized SCPI names or how few metrics are returned when data is missing.

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

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

A single front-loaded sentence with no filler; the comparison scope and metric list both earn their place. Slightly dense with the parenthetical metric enumeration, but nothing is redundant.

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?

Simple read-only tool with one fully documented parameter and no output schema, so the description carries the return-content burden — which it does by enumerating the compared metrics. Only minor gaps remain around error handling and accepted input format for SCPI identifiers.

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

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

Schema description coverage is 100% and the single 'scpis' parameter is documented in the schema, including minItems/maxItems. The description's '2 à 4' merely restates those constraints rather than adding format guidance (e.g. whether names must be exact, accent- or case-sensitive).

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

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

The description uses a specific verb ('Compare') with a clear resource ('SCPI') and states the cardinality (2 to 4) plus the exact metrics compared (prix, taux de distribution, taux d'occupation, capitalisation, frais, valeur de reconstitution). It implicitly distinguishes itself from single-entity siblings like fiche_scpi, but never names an alternative explicitly.

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

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

Usage is only implied: an agent can infer this is the tool for multi-SCPI side-by-side comparison, and the 2–4 bound is stated. There is no explicit guidance on when to use fiche_scpi or rechercher_scpi instead, nor any prerequisite such as needing valid SCPI names or identifiers.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value by listing the payload contents, including an external link, but says nothing about not-found behavior, whether the name match is fuzzy or exact, or the response shape.

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 front-loaded sentence that spends its words on the returned fields rather than restating the title. The field enumeration is long but each item earns its place by telling the agent what the sheet contains.

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 one required parameter, rich annotations and no output schema, the description does the main remaining job by enumerating the returned metrics. The only meaningful gap is edge-case behavior, e.g. what happens when the supplied name matches no SCPI or matches several.

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

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

Schema description coverage is 100% and the single parameter already documents both name and identifier with examples ('Transitions Europe', 'iroko'). The description adds no further semantics about accepted formats or matching tolerance, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Renvoie la fiche chiffrée d'une SCPI') and enumerates the returned metrics (prix, taux de distribution, capitalisation, frais, dernier bulletin), so the agent knows exactly what data this yields. It does not, however, contrast itself with siblings such as rechercher_scpi or comparer_scpi, which also operate on SCPIs.

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

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

Usage is only implied: the agent must infer this is the tool for pulling a full detail sheet on one identified SCPI. There is no explicit when-to-use versus rechercher_scpi (search) or comparer_scpi (comparison), and no stated prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing what the returned journey contains (regulatory questionnaire, entry-into-relationship document, adequacy report) and that these precede any signature, telling the agent this is a multi-step pre-contractual flow rather than an immediate transaction.

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 return value and followed by the one piece of context an agent needs. No filler or repetition of structured fields.

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

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

For a single-parameter read-only tool with full annotation coverage and no output schema, the description does what is needed: it names the returned artifact (an address/URL) and explains what that artifact leads to. Nothing required to invoke or interpret the result 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 the single 'scpi' parameter documented as 'Nom ou identifiant de la SCPI'. The description only restates this as 'pour une SCPI donnée' and adds no detail on accepted identifier formats, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: it returns the URL of the online SCPI Select subscription journey for a given SCPI. This is clearly distinct from the sibling tools (fiche_scpi, comparer_scpi, rechercher_scpi, acquisitions_recentes, mouvements_prix), none of which return an action link, though the description never explicitly contrasts itself with them.

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

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

Usage is only implied: an agent can infer this is the tool to call when a user wants to actually subscribe rather than view data. There is no explicit when-to-use statement, no mention of prerequisites, and no named alternative for users who only want information rather than a subscription path.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuine context beyond that: each movement is dated and sourced ('datées et sourcées') from the SCPI Select observatory, which tells the agent about data provenance and trustworthiness — especially valuable since there is no output schema.

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

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

A single dense sentence that front-loads the verb and resource, then layers provenance and the optional filter. No redundant or filler wording; every clause contributes.

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 tool is simple (two optional parameters, no output schema) and annotations cover the safety profile, so the description is close to sufficient. The remaining gap is what a 'mouvement' contains — date, source, old/new price, variation magnitude — and how results are ordered, which the description leaves unspecified.

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

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

Schema description coverage is 100%, so both parameters are already documented, giving a baseline of 3. The description reinforces that the SCPI filter is optional but adds no meaning about 'limite' (default 20, max 100) beyond what the schema already says.

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: lists upward and downward unit-price movements ('hausses et baisses de prix de part') from a named observatory. That is clearly distinct from sibling tools like fiche_scpi or comparer_scpi, although the description never explicitly names a sibling to contrast with.

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?

'éventuellement pour une seule SCPI' implies the optional filtering scenario, so the agent can infer when to pass the scpi parameter. However, there is no explicit guidance on when to prefer this tool over fiche_scpi or comparer_scpi for price information, and no stated preconditions.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's added value is provenance and output shape: it discloses that the catalogue tracks 50+ SCPI with figures taken from official bulletins and that the call returns one row per SCPI with price, distribution rate, occupancy rate and a link to the detail sheet. That is meaningful context beyond the annotations, though it says nothing about ordering, pagination, or what an empty result looks like.

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, both load-bearing: the first defines the resource and filter axes, the second defines the return shape. Front-loaded and free of filler, with only the parenthetical about catalogue size and data provenance adding slight bulk.

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

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

For a read-only, no-output-schema search tool the description supplies what an agent most needs: what can be filtered, where the data comes from, and what each returned row contains. The only material gap is the absent routing guidance relative to the five sibling tools and the mismatch around "catégorie".

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including defaults and the 60-result cap; the baseline of 3 applies. The description confirms that the text search spans name, manager and sector, but it also lists "catégorie" as a filter axis when no category parameter exists, adding mild ambiguity rather than clarity for that field.

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

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

The description opens with a specific verb and resource ("Filtre les SCPI du catalogue SCPI Select") and enumerates the available filter axes plus the shape of a result row, so an agent knows this is a filtered catalogue listing. It does not, however, contrast itself with siblings such as comparer_scpi or fiche_scpi, leaving the differentiation 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?

Usage is only implied: the enumerated filters suggest an agent should call this when it wants to shortlist SCPI matching criteria. There is no explicit statement of when to prefer this over fiche_scpi (detail on one SCPI) or comparer_scpi (side-by-side comparison), and no exclusions or prerequisites are given.

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