l0g.fr Risk Intelligence

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond those annotations: the output is deterministic, and the tool explicitly 'Ne produit aucune opinion d’investissement.' This helps an agent understand behavioral constraints that annotations do not capture.

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 dense sentence that front-loads the action and resource, then efficiently lists the pack's contents. There is no fluff or repetition of schema details, and every element contributes to understanding what the tool produces.

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

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

Given the presence of an output schema, rich annotations, and full schema coverage for parameters, the description is reasonably complete. It clarifies the deterministic nature, the non-opinion boundary, and the core contents of the research pack. It could be stronger with explicit usage alternatives, but nothing essential is missing for invoking the tool correctly.

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

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

Schema description coverage is 100%, so parameter meaning is already fully documented in the schema. The description adds no extra parameter syntax, defaults, or format details beyond what the schema provides, which aligns with the baseline 3 for high schema coverage.

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 ('Compose') and resource ('paquet de recherche déterministe'), and enumerates what the pack contains. It clearly conveys what the tool does and is distinguishable from the many get_* and search_* siblings, though it does not explicitly name a sibling it is not.

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 'en un appel' implies this tool bundles what sibling tools like get_claims, get_freshness, and get_risk_diff would otherwise provide separately. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, so usage guidance remains implied rather than explicit.

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, openWorldHint=false, idempotentHint, and non-destructive behavior. The description adds useful context about what the manifest contains and positions it as a non-scraping discovery path, but it does not disclose additional behavioral details such as caching, versioning, or stability.

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 concise, front-loaded sentences. The core return value is stated first, followed by content details and the recommended usage context. Every part earns its place with no 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, idempotent tool with an output schema and annotations covering safety, the description provides enough context to select and invoke the tool correctly. It also adds a clear discovery-oriented framing that helps the agent understand when to call 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 has zero parameters, so the schema already covers everything. The description adds no parameter information because none is needed; the baseline of 4 applies cleanly here.

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 ('Renvoie' / returns) and a specific resource ('le manifeste Agent Surface de l0g.fr'), and enumerates its contents: capabilities, endpoints, usage rules, proof policies, and counters. It clearly indicates what the tool does, though it does not explicitly contrast it with sibling tools by name.

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

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

The description explicitly recommends this tool as the entry point for discovering machine surfaces and even frames it as an alternative to scraping ('sans scraper'). It gives clear when-to-use context, though it does not mention specific sibling alternatives 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 mark it read-only and idempotent; the description adds pagination behavior (offset/length, nextOffset) and section shortcuts beyond that. 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?

Four sentences, tightly focused: purpose, pagination, section shortcuts, and alternative resource. The primary action is front-loaded and each sentence adds distinct 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 7-parameter tool with a full output schema, the description covers purpose, pagination, section selection, and the alternative full-object resource. The only small gap is that it doesn't explain how cursor/nextCursor relates to nextOffset, but that is documented in 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 coverage is 100%, but the description enriches the section parameter by mapping tail to conclusion/limitations/methodology and sources to sources, and clarifies that offset/length drive the returned segment. It doesn't repeat schema details, so it adds meaning beyond the parameter descriptions.

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

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

The opening sentence names a specific verb ('Renvoie'), a concrete resource (analysis or guide l0g), and the retrieval key (slug). The text-returning behavior distinguishes it from the sibling list/search tools, so an agent can tell it apart without opening the 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?

It gives clear usage context: use section=tail or section=sources for fast access to conclusion, limitations, methodology, and sources, and mentions the l0g://articles/{slug} alternative for full-object reads. It does not explicitly contrast with sibling tools like search_content or list_recent_analyses, so it misses the 'when-not-to-use' part.

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 establish read-only/idempotent/non-destructive behavior. The description adds meaningful behavioral detail: date selection is inclusive of the requested day and performs no retroactive reconstruction.

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 front-loads what is returned and then explains the date behavior without filler. Every clause earns its place.

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 an output schema, a 100%-described parameter schema, and safety annotations, the description covers the key behavioral nuances an agent needs. Nothing required for a correct call 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 100%, so the baseline is 3. The description adds the important date semantics (last frame on or before the date, no retroactive reconstruction) beyond the schema's basic type description.

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

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

The description names a specific verb ('Renvoie') and resource ('Black Box Recorder l0g'), and clarifies the content as point-in-time hashed frames of risk signals. This is distinct enough from siblings like get_risk_diff or get_risk_indices.

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 implied by the purpose: it is the tool to consult for point-in-time risk-signal frames, with optional date replay. It does not explicitly state when to prefer it over siblings or when not to use it.

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, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context about what the feed contains and its diff-related output, but does not disclose details like ordering, time-window, or pagination behavior beyond the limit parameter.

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 concise sentences: the first fronts the returned data, and the second gives the intended use case. There is no filler, repetition, or unnecessary 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?

For a simple, read-only, zero-required-parameter tool with a full input schema and an output schema, the description is complete enough. It names the returned artifact types and fields, and states the intended monitoring scenario, so an agent can decide whether to call it without additional context.

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 both parameters (limit and contentType) adequately. The description adds no extra parameter-level meaning beyond its mention of content types, which aligns with the schema's enum. Baseline 3 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 a specific verb ('Renvoie') and the resource (latest publications, revisions, policies), and lists key returned fields (objectId, current version/hash, diff status, semantic change). It also conveys a distinct monitoring purpose, which separates it from sibling tools like get_ndjson_feed or get_changes.

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

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

The description explicitly says to use it for monitoring the corpus without rescanning everything ('À utiliser pour surveiller le corpus sans tout rescanner'), providing a clear context. It does not mention when not to use it or name alternative tools, so it misses the full exclusionary guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is fully covered. The description adds modest context by naming output fields and the minimum-date filter, but it does not disclose ordering, pagination, or how diff status is computed.

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

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

The description is two short sentences, front-loaded with the main action and free of filler. It packs the supported filters and key output highlights into a compact, readable form.

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 an output schema present and annotations covering safety and idempotency, the description is largely sufficient for invoking the tool correctly. It lacks only an explicit pointer toward when to use raw changefeed siblings, and it leaves limit/pagination details 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 coverage is 100%, so every parameter already has a description. The description adds minimal extra semantics by mapping 'type' to contentType, 'slug' to filtering, and 'since' to a minimum date, but it adds nothing about the limit parameter. This meets the baseline for high schema coverage.

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 ('Interroge') and names a resource ('changefeed machine'), then lists the available filters and included result fields. It is clear, but it does not explicitly contrast with the sibling get_changefeed, so it stops short of full sibling differentiation.

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 this is the filtered, semantic changefeed view by mentioning filters and 'type de changement sémantique', but it never explicitly states when to prefer it over get_changefeed or get_ndjson_feed, nor gives any exclusion conditions.

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, and destructiveHint, covering the safety profile. The description adds useful behavioral context by stating that references are clickable and dated when detectable, which goes beyond the annotations without contradicting them.

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, with two sentences and the main action front-loaded. It earns a 4 rather than 5 because of the cryptic 'trois relations affirmation-source structurantes' wording and the 'l0g' typo, which force extra parsing effort.

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 a complete input schema, output schema, and annotations, the description does not need to re-explain parameters or return structure. It provides enough orientation for an agent to understand the tool's purpose and main filters, though the ambiguous relationship phrase and typo leave some room for improvement.

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 8 parameters already have descriptions in the schema. The tool description only names three filter dimensions and adds no extra constraints, defaults, or interplay between parameters, so the baseline 3 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 uses a specific verb ('Interroge') and identifies the resource (claim-source relations) plus the main filter dimensions (article, claim type, text) and output (clickable references). It is mostly clear, but the phrase 'trois relations affirmation-source structurantes' and the apparent typo 'l0g' keep it from being fully 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 explicitly names the key filtering contexts: article, claim type, and text, which gives an agent a clear sense of when to call this tool. It does not mention when not to use it or point to sibling alternatives, so it falls 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.

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds meaningful behavioral context: with articleSlug, direct evidence is separated from related content via host/source/dataset relationships. 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 two concise sentences with no filler. The main purpose is stated first, followed by the key conditional behavior, making it easy for an agent to parse quickly.

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

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

Given the rich annotations, complete parameter descriptions, and presence of an output schema, the description covers the essential behavioral and scoping information. The main gap is the lack of usage guidance relative to sibling tools, but for a read-only graph retrieval tool with no required parameters, the definition 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?

The input schema already documents all four parameters with 100% coverage, so the baseline applies. The description adds semantic value by explaining the behavioral effect of articleSlug: separating direct evidence from indirectly related content, which goes beyond the schema's 'voisinage de graphe' phrasing.

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 returns an evidence subgraph and enumerates the node types (articles, claims, references, hosts, primary sources, datasets). It does not explicitly distinguish this tool from siblings like get_article or get_claims, but the graph-specific framing is clear enough for basic identification.

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 no guidance on when to use this tool versus alternatives such as get_article, get_claims, or search_by_topic. The only conditional statement concerns articleSlug behavior, which is a parameter detail rather than usage guidance.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds valuable behavioral context by explaining that the tool reports freshness state, including counters and policy, and frames it as a pre-check before asserting currency. No contradiction with annotations exists.

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

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

The description is two sentences with no filler. The main purpose is front-loaded, and the usage note is compact and relevant. Every word earns its place.

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: one optional parameter and no required inputs. The description states what the tool returns, and an output schema exists to provide structured return details. Nothing necessary for calling the tool 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?

The input schema fully documents the single optional limit parameter with default, minimum, and maximum, so schema coverage is 100%. The description does not mention limit, but the schema carries the full semantic burden and the description does not need to compensate.

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 ('Renvoie') and resource ('fraîcheur du corpus l0g'), then enumerates what the tool returns: latest contents, counters, available endpoints, and freshness policy. This clearly separates it from siblings like get_changes or get_changefeed, which focus on content changes rather than corpus freshness metadata.

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 explicit guidance: call this tool before presenting a snapshot as current. This is a clear, actionable usage context. It does not enumerate when not to use the tool or name alternatives, but the stated use case is sufficient for most decision-making.

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?

The description goes beyond the read-only and idempotent annotations by naming exactly what is returned: canonical SHA-256 fingerprints across three surface types. It does not explain domain terms like 'Agent Surface' or what happens when path is omitted, but the annotations already establish the safety profile and no contradiction is present.

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 sentences front-load the core output and then provide a concrete use case. Every sentence earns its place; there is no fillr 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 read-only, idempotent tool with one optional parameter and an output schema, the description is mostly sufficient. It could be more complete by defining 'Agent Surface' and explaining the default behavior when path is omitted, but the schema and annotations cover most operational 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?

The-only optional path parameter is fully described in the schema, and the description does not add further meaning about how path selects or filters surfaces. With 100% schema description coverage, the baseline 3 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 uses a specific verb and resource: it returns canonical SHA-256 fingerprints for the Agent Surface, JSON, and NDJSON surfaces, which clearly identifies the operation. However, it does not explicitly differentiate itself from siblings like verify_artifact or get_freshness, so sibling 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?

It states a concrete use case: verifying that an agent ingested a precise snapshot. It does not, however, say when to prefer this tool over alternatives such as verify_artifact or get_changefeed, nor does it provide any 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 cover read-only/idempotent/non-destructive behavior. The description adds a meaningful extra behavioral constraint: only allowlisted public feeds are accepted and arbitrary paths are rejected, and clarifies the data is the public NDJSON variants. This goes beyond what the annotations 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?

Two compact sentences, no filler: the first sentence states the tool's scope and enumerates valid feeds, the second adds the key security constraint. Information is front-loaded.

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 tool with a complete input schema, annotations, and an output schema, the description covers the essential call constraints and feed choices. It is slightly incomplete only in not relating the feed variants to the dedicated sibling endpoints, but an agent can still invoke 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 the parameters are already documented. The description mainly restates the feed enum values in prose and adds the 'public/NDJSON' context, but does not add detail about limit or recordType beyond the schema; baseline 3 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 uses a clear verb ('Lit') and a specific resource ('variantes NDJSON publiques de l'Agent Surface'), and enumerates the five allowed feed names, so an agent can see what the tool operates on. It does not explicitly contrast itself with similarly named siblings such as get_claims or get_changes, so it loses a point on differentiation.

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 when-to-use guidance or mention of alternatives. The only constraint stated is the allowlist/no-arbitrary-path restriction; the description never tells the agent when to choose this raw NDJSON tool over get_claims, get_changes, get_evidence_graph, or get_signal_history.

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 read-only, idempotent, and non-destructive behavior. The description adds that the contract is public and that summary mode avoids full-file retrieval, which is useful context, but it does not go far beyond the annotation-provided safety profile.

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 concise sentences that front-load the core purpose and then add the summary-versus-full-file nuance. There is no filler or redundant elaboration.

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?

This is a simple discovery tool with rich annotations, fully described parameters, and an output schema. The description covers the essential context for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% and both parameters already have detailed descriptions, including the mode enum values and path format example. The description reinforces the 'summary suffices' idea but does not add meaningful parameter semantics beyond the schema.

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

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

The description clearly states that the tool exposes the public OpenAPI contract of the Agent Surface l0g and that it enables discovery of paths, methods, and schemas. It is easily distinguishable from all sibling tools, none of which target the OpenAPI contract.

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: discover the API contract and avoid retrieving the full file when a summary suffices. However, it does not explicitly name alternative tools or define when this tool should be preferred over siblings, so the guidance remains implied rather than explicit.

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 mark it read-only, idempotent, and non-destructive, and the description is consistent with these. It adds useful context by specifying that the log includes signals, fresh/stale sources, claims, models, related articles, and confidence level, going beyond a generic 'returns data' statement.

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 concise sentences with no fluff: the resource and scope are front-loaded, followed by a compact content list. Every clause earns its place.

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 has a single optional enum parameter and an output schema, so the description does not need to explain return values. It covers what the log contains and the supported windows, making it complete enough 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 100%: the single optional window parameter is already documented with its enum values and meaning. The description reinforces '1, 7 or 30 days' but does not add new semantic detail beyond what the schema provides, so baseline 3 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 uses a specific verb ('Renvoie') and names a distinct resource, the 'Risk Diff l0g', with a clear scope: changes in risk over 1, 7, or 30 days. It also enumerates contents such as signals, sources, claims, models, articles, and confidence, distinguishing it from siblings like get_changes or get_freshness.

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 temporal windows and 'ce qui a changé dans le risque' give a clear implied use case for historical risk-diff checks. However, it does not explicitly say when to prefer this over closely related siblings such as get_changefeed, get_changes, or get_risk_indices, nor does it state 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, and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond annotations: data source, snapshot cadence, non-real-time nature, inclusion of the 13F confluence summary, and a non-advice disclaimer.

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, packed with the essential specifics: publisher, dashboard coverage, snapshot cadence, 13F summary, real-time caveat, and disclaimer. Every sentence contributes meaning without 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 parameterless read-only tool with an output schema and safety-related annotations, the description covers the main operational context: what data is included, from whom, and at what freshness. It could be slightly richer about how the risk indices are structured, but the output schema likely fills that gap.

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, and the schema reflects that with 100% coverage, so there are no parameter semantics for the description to clarify. Baseline for zero parameters is 4; the description appropriately focuses on content rather than parameters.

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: risk indices published by l0g.fr, including specific dashboards and a 13F confluence summary. It is unambiguous about what the tool returns, though it uses a noun phrase rather than a verb and does not explicitly name a sibling for differentiation.

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 definition implies usage context by noting snapshot cadence and explicitly stating 'Pas de temps réel strict' (not strict real-time), which helps an agent avoid using it for real-time needs. However, it does not name alternative tools or provide explicit when-to-use versus when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail about what the response contains (dated observations, level changes, current scores, etc.), but says nothing about pagination, default limits, or filtering semantics beyond what the schema states.

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 information-dense sentence that front-loads the main returned entity. Its length is justified by the need to enumerate several output categories, though it relies on domain jargon such as 'l0g' and '13FLOW'.

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 a simple read-only query with two optional, fully documented parameters and an output schema present, so the description need not restate schema details. The listed output facets plus annotations give sufficient context for an agent to invoke it correctly, though a short usage-preference note relative to sibling tools would make it more 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?

Input schema coverage is 100%: the 'key' parameter has an explicit enum and description, and 'limit' has default/min/max plus a description. The tool description does not need to re-explain these, 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 uses a specific verb ("Renvoie") and resource ("les observations datées des séries l0g") and enumerates the returned data categories (citable identity, methodological version, level changes, scores, 13FLOW confluence). It is clear about what the tool does, though it does not explicitly differentiate it from sibling tools such as get_changes or get_risk_diff.

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 guidance about when to choose this tool over the many sibling get_* tools, nor any when-not-to-use or exclusion criteria. The intended use is only implied by the phrase 'Renvoie les observations...' and 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?

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context about scope and output fields, but it does not disclose ordering, pagination, or freshness. Given the annotations, a mid score is appropriate.

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 includes the action, resource, representative examples, and output fields. There is no filler, and the core information is front-loaded.

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?

This is a simple read-only tool with one optional parameter, full annotation coverage, and an output schema. The description sufficiently covers scope and examples; return values are already handled by the output 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 coverage is 100%, and the only parameter, language, is fully documented with an enum and description. The tool description adds no substantial parameter semantics 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 states a specific action ('Liste') on a precise resource ('les guides de référence de l0g.fr'), gives concrete topic examples, and lists the returned fields. This clearly separates it from siblings like list_sources or list_recent_analyses by domain, even without naming 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 implied: an agent can infer this tool is for retrieving a catalog of durable reference guides. However, the description does not explicitly name alternatives or conditions for when to use another sibling tool.

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 mark the tool read-only and non-destructive. The description adds behavioral context by disclosing the sort order, the source site, and the response fields. It does not contradict annotations and provides useful detail beyond the safety hints, while the output schema covers the remaining return structure.

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 contains the action, scope, ordering, and returned fields with no filler or repetition. Every element earns its place.

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 operation with two optional parameters and an output schema, the description plus annotations and schema provide everything needed: source, ordering, returned fields, parameter defaults, and enum values.

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 100% description coverage for both limit and language, including defaults, constraints, and enum values. The description does not add extra parameter semantics, but the schema already carries the burden fully.

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 ('Liste les analyses les plus récentes de l0g.fr'), specifies the ordering ('de la plus récente à la plus ancienne'), and enumerates the returned fields (titre, URL, date, description, thèmes). This clearly distinguishes it from siblings like get_article and search_content.

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: it is the tool for listing recent analyses from l0g.fr in reverse chronological order. It does not explicitly name alternatives or when-not-to-use cases, but the scope is precise enough that an agent can infer when to select it.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the scope of the data returned, but it does not disclose additional behavioral traits such as pagination behavior, result limits, or any response characteristics beyond what the output schema would already provide.

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 one focused sentence with a short clarifying use-case clause. It is front-loaded with the verb and resource, contains no fluff, and every part contributes to understanding the tool's purpose.

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

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

Given the rich annotations, full parameter descriptions in the schema, and presence of an output schema, the description is sufficient for an agent to call this tool correctly. It communicates the tool's scope and intended use without leaving critical 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 description coverage is 100%, and every parameter already has a meaningful description in the schema. The tool description does not add extra meaning about parameters, so the baseline score 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 clearly states the tool lists primary institutional sources tracked by l0g and hosts actually cited by claims, which is a specific verb+resource combination. It distinguishes list_sources from sibling list tools like list_guides and list_recent_analyses by naming the exact entities returned.

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 a clear use case: auditing the origin of evidence. It does not explicitly mention when not to use this tool or name alternatives, but the stated purpose is enough for an agent to select it in the appropriate context.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: it accepts a slug or approximate label and, on resolution failure, returns the available topics. This helps the agent anticipate tolerant input and recover from invalid topic values.

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 compact sentence with two clauses: the main action is front-loaded, and the error behavior is appended without repetition. Every clause earns its place, and there is no filler or redundant restating of the tool name.

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 search tool with three simple parameters and an output schema, the description plus schema cover the inputs, tolerance behavior, and failure mode. The main omission is explicit routing guidance between this tool and search_content, though that gap is already captured under usage_guidelines.

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 covers all three parameters with descriptions, so the baseline is 3. The description adds meaningful nuance for the topic parameter by specifying 'slug ou un libellé approchant' and clarifying that unresolved topics trigger a response containing available topics. This goes beyond the schema's one-line parameter descriptions.

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

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

The description states a specific verb and resource: 'Liste les analyses rattachées à un sujet (hub thématique) de l0g.fr.' This clearly identifies a topic-scoped search tool, but it does not explicitly differentiate it from sibling tools such as search_content, so it stops short of full sibling differentiation.

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 its usage context by mentioning that it accepts a slug or approximate label and returns available topics on resolution failure. However, it gives no explicit guidance on when to prefer this tool over alternatives like search_content or list_recent_analyses, leaving selection largely to inference.

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 and idempotentHint, so the safety profile is covered. The description adds useful behavior beyond that: the index is bilingual by default, shared with Agent Surface and WebMCP, has no external provider, and catalog mode uses legacy scoring on title, tags, topics, and description. This gives the agent meaningful execution context without contradicting 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 two sentences with no filler. The first sentence front-loads the tool's purpose and scope, and the second sentence explains default behavior and the mode distinction. Every clause 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 search tool with four documented parameters, an output schema, and safety annotations, the description covers the essential context: what is searched, over which content, how the default index behaves, and what catalog mode changes. It is not fully complete only because it does not position the tool against its closest siblings.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining that the default index is the bilingual canonical one and that catalog mode preserves legacy scoring on title, tags, topics, and description. This enriches the mode and language parameters beyond their schema descriptions.

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

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

The description states a specific verb and resource: full-text local search over l0g.fr content types (analyses, guides, glossary, methodological sheets, primary sources). It clearly separates fulltext and catalog behavior, but it does not explicitly distinguish itself from sibling tools such as search_by_topic or list_recent_analyses, so it falls just short of full differentiation.

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 clear context: use it for local full-text search across l0g.fr, with a bilingual canonical index by default and an optional legacy catalog scoring mode. It does not explicitly say when to prefer search_by_topic or another sibling over this tool, so it lacks explicit exclusions and alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those flags: the verification is based on a published integrity manifest, and path resolution is restricted to known snapshots, preventing arbitrary access. This usefully clarifies the safety and scope boundaries.

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 resource, followed by the key scope restriction. Every sentence contributes meaningful information and there is no redundancy with the schema or annotations.

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, has an output schema, and its annotations already cover read-only, idempotent, non-destructive behavior. The description provides the essential semantic restriction (known snapshots only) and the verification source (integrity manifest). Nothing critical is missing for an agent to correctly select and invoke 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?

Schema description coverage is 100%, so the baseline is 3. The description adds the important constraint that path must be a known snapshot and that no arbitrary path reading occurs, which gives semantic meaning to the path parameter. However, it does not elaborate on the optional sha256 parameter or verification comparison behavior beyond what the schema already states.

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 ('Vérifie') and a specific resource type (artefact Agent Surface) tied to a published integrity manifest. It also distinguishes itself from generic arbitrary file reads by clarifying it only verifies known snapshots, which differentiates it from sibling getters like get_integrity or get_artifact-like 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 gives clear usage context: call it only when the path corresponds to a known snapshot and verification against the integrity manifest is intended. It explicitly warns that arbitrary path reading is not performed, effectively telling the agent when not to use this tool, though it does not name alternative tools directly.

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