Valeur Intrinsèque

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

With no annotations, the description carries the full behavioral burden, and it does disclose the return payload in useful detail. However, it says nothing about whether the call is read-only (inferable but unstated), data freshness/source, latency (a full fundamental analysis may be slow), or failure modes for invalid tickers. Read-only analysis is low-risk, but the disclosure is incomplete.

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 core purpose in the first clause, then a compact enumeration of outputs. The list of 10 criteria is slightly verbose but earns its place given there is no output schema to describe the 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?

No output schema exists, so the description must convey the return shape, and it does so adequately (profile, intrinsic value, margin of safety, /100 score, ten criteria, key financials). It is complete enough for an agent to select and call it correctly; only interpretation guidance for the score and data-source caveats are 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?

There is only one parameter and schema description coverage is 100%, including an example ticker format, so the schema already does the work. The description adds nothing about symbol semantics (e.g. exchange suffixes, whether the analysis adapts to non-US markets despite the French-language scoring method). Baseline 3 applies.

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

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

The description names a specific verb and resource ('Analyse fondamentale complète d'une action') and enumerates what the analysis produces (Score VI, intrinsic value, margin of safety, 10 quality criteria). This clearly distinguishes it as a composite/aggregate analysis rather than a single-metric getter, though it never names the sibling it displaces (e.g. get_intrinsic_value, get_valuation_metrics).

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 word 'complète' implies this is the full-picture tool as opposed to the granular sibling getters, so usage is implied but never stated. There is no explicit when-to-use/when-not-to-use, no mention that it subsumes get_intrinsic_value or get_valuation_metrics, and no prerequisites (e.g. whether deeper data is needed for certain tickers).

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

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

With no annotations, the description carries the full behavioral burden. It does disclose that it reads the public cache and does not trigger a full analysis (useful cost/freshness context), but says nothing about read-only guarantees, what happens when a ticker has no published VI Score, or whether the cache can be stale. For a tool with zero annotation coverage this is a substantial 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 short sentences with zero filler; the comparison scope and the cache-read caveat are front-loaded, so an agent gets the essentials immediately.

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 one-parameter tool with full schema coverage, the description is nearly sufficient and partially compensates for the missing output schema by naming the returned fields (price, P/E, note /100). It falls just short on edge-case behavior (missing/unpublished scores) and the absent annotations.

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

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

Schema description coverage is 100% and the single symbols parameter already documents the 2-8 ticker constraint with an example. The description adds no syntax or format detail beyond that, 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 (compare) and resource (stocks) and goes further by naming the comparison basis — the published VI Score — plus the fields surfaced (price, P/E, note /100). It implicitly distinguishes itself from analyze_stock via 'without re-running a full analysis', though no sibling is named outright.

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 phrase 'Lit le cache public, sans relancer une analyse complète' implies the usage context — use this for lightweight comparison rather than a full analysis. However, it never explicitly states when to prefer this over analyze_stock or screen_stocks, leaving the agent to infer the routing.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the data source (sources publiques) and freshness (mises à jour quotidiennement), which are genuine behavioral traits, but says nothing about authentication needs, rate limits, or return 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?

Two sentences, no filler. The scope (5 years, statement types) is front-loaded in the first sentence, and the data-provenance detail follows where it belongs.

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 tool with no output schema and no annotations, the description covers scope, statement types, data origin, and freshness. It is nearly complete, though permission/error behavior remains unstated.

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 (symbol, statement) including the enum values are fully documented in the schema itself. The description adds no parameter semantics beyond what the schema already provides, 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+resource ('Retourne les états financiers historiques') and scopes it precisely (5 dernières années, three statement types). It is clearly distinguishable from price/valuation siblings by topic, but it never names or contrasts any sibling tool 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?

The description implies when the tool is useful but gives no explicit when-to-use guidance, no alternatives (e.g. get_valuation_metrics, analyze_stock), and no exclusions. An agent must infer the selection context on its own.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the shape of the result (a /100 score, 10 quality criteria, price, estimated intrinsic value), which tells the agent this is a read-style analytical tool, but it says nothing about failure behavior for an invalid ticker, data freshness, or performance characteristics.

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 short sentences, with the concrete return contents front-loaded. The second sentence is largely a marketing-style claim ('l'outil de référence') that adds marginal value, but it is brief and does not bloat the definition.

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 correctly compensates by enumerating the returned fields, which is the key information an agent needs. It stops short of covering error handling or data freshness, but for a single-parameter read tool it is largely complete.

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

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

There is only one parameter and schema description coverage is 100%, with the schema itself giving a ticker format example (AAPL, MSFT, MC.PA). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Retourne le Score VI ... le cours et la valeur intrinsèque estimée') and enumerates exactly what is returned, so an agent knows what the tool produces. However, it does not distinguish itself from close siblings such as get_valuation_metrics or analyze_stock, which also touch valuation, leaving some ambiguity about which to pick.

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

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

There is no explicit when-to-use guidance or comparison against the nine sibling tools. The phrase 'C'est l'outil de référence pour interroger Valeur Intrinsèque' asserts primacy but never says when this tool is preferable to get_valuation_metrics or when it should not be used.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the result range (1–5) and the evaluation criteria, which is genuine context beyond the schema. It is silent, however, on whether the score is returned as a single number or a per-criterion breakdown, on error behavior for an invalid ticker, and on any latency or cost.

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 short sentences with no filler; the purpose is front-loaded and the rubric follows. Slightly terse for a tool with no annotations or output schema, 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 single-parameter analytic tool with no output schema, the description covers what is measured and the output scale, which is the core need. It leaves open the shape of the response (single score vs. criterion breakdown) and any failure modes, so it is adequate rather than complete.

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

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

Schema description coverage is 100% and the single parameter 'symbol' is already documented as a ticker with an example (AAPL). The description adds no parameter-level meaning beyond that. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Évalue la qualité du management d'une entreprise') and quantifies the output scale (1 à 5). The rubric criteria (track record, allocation du capital, communication, alignement actionnaires) sharpen what is being measured. It does not explicitly distinguish itself from the close sibling get_moat_score, which keeps it from 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?

No indication of when to reach for this tool versus get_moat_score, get_intrinsic_value, or the general analyze_stock. There are no prerequisites, no exclusions, and no sequencing guidance. The agent must infer usage purely from the tool name.

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

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

With no annotations, the description carries the full burden, but it does add one genuinely useful trait: the score is AI-generated from fundamentals and competitive positioning, implying a subjective estimate rather than a raw figure. It omits permissions, determinism/caching, rate limits, and how to interpret the 1-5 output, leaving meaningful gaps for an unannotated 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?

Two tight sentences with zero waste; the purpose and scale are front-loaded, and the origin of the score follows as supporting context.

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 one-parameter scoring tool with no output schema, the description covers the scale range but gives no anchors for what 1 versus 5 means and does not describe the response shape, which is fair game absent an output schema. Adequate but with clear 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?

Schema coverage is 100% and the single parameter (symbol) is documented with an example ticker, so the schema does the work. The description adds nothing about the parameter, making the baseline 3 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?

States a specific verb (évalue) and resource (avantage concurrentiel / economic moat) and even gives the scale (1 à 5), which cleanly separates it from siblings like get_intrinsic_value and get_management_score. It does not explicitly name or contrast those siblings, so it stops short of a 5.

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

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

The description says what the tool computes but never says when to reach for it versus analyze_stock, get_intrinsic_value, or get_management_score, nor any prerequisite or exclusion. The agent is left to infer usage entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the upstream data source (Yahoo Finance), but says nothing about return shape (OHLCV series?), rate limits, auth needs, or how missing/delisted tickers are handled — significant gaps for a data-retrieval 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?

Two short sentences, front-loaded with the core action and no filler. The second sentence justifies its place by hinting at use cases, though it could be more specific.

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 three fully documented params and two enums, the input side is covered; but there is no output schema and the description never hints at the return format an agent must reason about. Adequate but with a clear gap for a data-returning tool.

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

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

Schema description coverage is 100%, so symbol, range and interval are already documented with defaults and enums in the schema. The description adds no additional meaning (e.g. interpretation of interval vs range interaction), 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+resource: returns the price history of a stock, with the data source (Yahoo Finance) named. It does not differentiate itself from the close sibling get_stock_price, which an agent could easily confuse with historical-vs-current pricing.

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?

"Utile pour tracer un graphique ou analyser la tendance" implies when to reach for this tool, but offers no explicit routing against siblings such as get_stock_price or analyze_stock, and no exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden. It discloses that the return includes the currency, which is useful beyond the schema, but it does not state data freshness (real-time vs delayed), market/exchange handling, or failure behavior for invalid tickers.

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 short, front-loaded sentence with zero padding or repetition. Nothing is wasted, though there is also very little content to structure.

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

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

For a single-parameter read tool with complete schema coverage, the description covers what is returned (current price plus currency). Freshness/quote-delay semantics are the only notable gap, and they are minor for this tool's complexity.

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 single 'symbol' parameter is fully documented in the schema (100% coverage, with examples like AAPL, MC.PA), so the schema does the heavy lifting. The description adds no format or constraint detail beyond it, which is the baseline case.

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 ('Retourne le cours actuel d'une action') and adds the scope detail that the currency is included. It is clearly distinguishable from siblings like get_price_history or get_valuation_metrics, though it does not name any of them 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?

There is no statement of when to use this tool versus alternatives such as get_price_history or compare_stocks, and no prerequisites or exclusions. Usage must be inferred entirely from the tool name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a read-only operation, does not describe the return structure or pagination, and gives no auth or rate-limit context. It only lists the metric types, which is content rather than 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 short sentences, front-loaded with the concrete list of returned metrics and followed by the use case. No filler or redundancy, though it is terse enough that it forgoes any structural cues about scope or 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?

For a simple one-parameter read tool with no output schema, the description compensates by enumerating the returned metrics and their time span. Nothing essential for correct invocation is missing, though the absence of any output-shape or historical-window detail keeps it from being fully self-sufficient.

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

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

Schema description coverage is 100% for the single 'symbol' parameter, so the schema already documents the ticker format and example. The description adds no syntax, format, or scope detail beyond what the schema provides, making the baseline 3 correct.

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 (historical valuation metrics) and enumerates the exact metrics returned (P/E, P/B, PEG, EV/EBITDA) over a multi-year window. This is clearly more than a restatement of the name, but it does not distinguish itself from siblings like get_intrinsic_value or analyze_stock, which occupy adjacent valuation territory.

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?

Provides an implied use case ('utile pour évaluer si une action est chère ou bon marché par rapport à son historique'), which tells the agent when this tool is relevant. However, it offers no explicit alternatives, no when-not guidance, and no mention of how it differs from get_intrinsic_value or analyze_stock.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return contents (price, valuation, margin of safety) and the descending-score ordering, but says nothing about what 'récemment analysées' means, how the list is refreshed, or any pagination/auth behavior. Partial coverage of a tool with zero annotation support.

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 compact clauses, front-loaded with the action and resource, and no wasted words. The return-contents clause earns its place since there is no output 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 simple read-only list tool with one optional parameter and no output schema, the description covers what is returned and how it is ordered, which is the essential information. Missing pagination/refresh details keep it short of a 5.

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?

There is a single optional parameter ('limit') with 100% schema description coverage, so the schema already documents default and max. The description adds no additional meaning about limiting or result counts, which is the expected 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 verb and resource ('Retourne les résultats du screener') and adds scope detail: recently analyzed stocks with their VI Score, sorted by descending score. It does not explicitly differentiate itself from siblings like analyze_stock or compare_stocks, but the screener framing is distinct enough that an agent can identify it.

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 never says when to use this tool versus the many sibling analysis tools, nor does it state prerequisites or exclusions. Usage is only implied by the word 'screener'; no alternative-routing guidance is given.

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