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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context by stating that the tool also returns exclusions that require manual review, which is non-obvious and beyond the structured metadata. 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 primary purpose is front-loaded, and the additional return behavior is stated efficiently.

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 low complexity, two parameters, and rich annotations, the description covers the necessary context well. It explains the input domain and calls out the exclusions return value, though with no output schema it could go slightly further in describing the exact response structure.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by explaining that the target parameter accepts a URL, domain, or IPv4, and by tying the operation to a program's declared scopes. The program_slug parameter is somewhat implicit, but the pattern and tool name make its role reasonably inferable.

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

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

The description clearly states the tool's specific verb ('Vérifie techniquement') and resource ('si une URL, un domaine ou une IPv4 correspond aux scopes déclarés d'un programme'). It also communicates an additional outcome (returning exclusions for manual review), which fully distinguishes it from sibling tools like get_program or search_programs.

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 intended use is implied by the description: call this tool to check whether a target is in scope for a program. However, it does not explicitly state when to prefer it over alternatives or when it should not be used, so the usage guidance is present only by implication.

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 minimal behavioral context beyond the action itself; it doesn't discuss limitations like max 5 programs or error behavior. With annotations providing the core safety info, a 3 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, well-structured sentence that front-loads the verb and resource. No filler, and every word contributes to the 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?

The tool has two parameters and no output schema. Annotations cover safety, but the description omits the meaning of include_rules and the limit on number of programs (max 5). For a read-only comparison tool, some gaps remain, but the core purpose is clear. Adequate given moderate 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?

Schema description coverage is 0%, so the description is the only textual source for param meaning. It explains what the comparison yields (rewards, costs, scopes, constraints) but does not explain the 'slugs' parameter or the 'include_rules' flag. The schema's pattern gives some hint for slugs, but the description leaves include_rules undocumented. It adds partial value over the schema but doesn't fully 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 states a specific verb ('Compare'), the resource (programs), and the exact attributes being compared (rewards, credit costs, scopes, main constraints). This clearly distinguishes it from siblings like get_program (single program details) and search_programs (finding programs).

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 purpose implies usage for comparing multiple programs, which is clear. However, it does not explicitly state when not to use it or mention alternatives. Given the sibling set, an agent could infer use cases, but explicit exclusions are absent.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds value by specifying the exact output scope: only the number of credits, and explicitly what is not returned (other profile data). This clarifies the return behavior beyond the annotations.

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

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

The description is a single sentence with no wasted words. It front-loads the core action (returning the credit count) and the key limitation (not exposing other profile data) in a compact, efficient 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 zero-parameter, read-only tool with annotations covering safety and idempotency, the description is fully adequate. It states exactly what is returned (the credit number) and what is excluded, giving an agent all necessary information. Since there is no output schema, the description's implication of a numeric balance is 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?

The tool has zero parameters, and schema description coverage is 100% (since there are no properties). The description correctly adds no parameter information because none exist. Per the baseline for zero-parameter tools, a score of 4 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 states a specific verb (Retourne), resource (crédits), and scope (hunter connecté), and explicitly limits output to the credit count, excluding other profile data. This clearly distinguishes it from the sibling get_my_credit_history, which would provide transaction history, so an agent can select it without opening schemas.

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 clearly implies when to use this tool: to get the current credit balance without additional profile details. It does not name alternatives explicitly, but the phrase 'sans exposer les autres données du profil' and the tool name itself make the usage context obvious. A brief mention of get_my_credit_history as the alternative for history would have made it perfect.

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 read-only safety profile is covered. The description adds that output is paginated and scoped to the connected hunter, but does not mention ordering, transaction types beyond gains/dépenses, or any pagination metadata returned.

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

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

A single dense sentence that front-loads the resource, scope, and pagination behavior with 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?

The tool is simple, has no required parameters, and is well covered by read-only annotations. However, there is no output schema and the description does not describe the shape of each history item or how pagination is represented in the response. An agent can safely invoke it, but may not fully anticipate the returned data.

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

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

Schema description coverage is 0%, so neither page nor page_size has textual documentation. Still, the names, constraints, and defaults are self-explanatory, and the word 'paginé' signals that both parameters control pagination. The description adds conceptual context but does not explicitly explain parameter effects.

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

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

The description uses a specific verb ('Liste'), a precise resource ('l'historique paginé des gains et dépenses de crédits'), and a scope ('du hunter connecté'). It clearly differentiates this from sibling get_my_credit_balance because it is a paginated history of credit movements rather than a current balance.

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 intended use is clear from the description: fetch a paginated credit transaction history for the current hunter. However, the description does not explicitly state when to use this tool instead of get_my_credit_balance or other siblings, leaving the distinction to be inferred from names and 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond that: attachment URLs are omitted by default, which informs the agent about default output 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, no filler. The main purpose comes first and the behavioral default is stated second. Every sentence 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 retrieval tool with two self-explanatory parameters and strong safety annotations, the description covers the core purpose and an important default behavior. The absence of an output schema is mitigated by the simplicity of the expected 'report detail' result.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It indirectly addresses include_attachment_urls by stating attachment URLs are omitted by default, but it repeats what the schema's default:false already conveys, and it adds no meaning for report_id.

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 ('Récupère') and resource ('le détail d'un rapport'), and scopes it to reports accessible to the connected hunter. This is clear, though it does not explicitly distinguish itself from sibling tools like get_report_activity or list_my_reports, 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?

No guidance is given on when to use this tool versus alternatives such as list_my_reports or search_my_reports. The scope 'accessible to the connected hunter' hints at a limitation, but there is no explicit when-to-use or when-not-to-use instruction.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds context about which program facts are returned, but it does not disclose further behavior such as error cases, availability restrictions, or output format.

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

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

The description is a single focused sentence that starts with the action verb and immediately states the target resource and lookup key. Every word earns its place and there is no redundant padding.

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

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

For a simple read-only two-parameter tool, the description covers the main purpose and the core returned data categories, while annotations cover side effects. It is not fully complete because include_rules is undocumented and there is no routing guidance or mention of prerequisites such as obtaining the slug from a list/search 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 0%, so the description must compensate. It clarifies that slug is the lookup key, but it says nothing about the include_rules boolean; the statement that rules are always retrieved could even obscure the fact that this parameter controls rule inclusion.

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 the specific verb 'Récupère' (retrieves), targets a precise resource ('un programme') and identifies the key by slug. It further distinguishes this tool from sibling program-related tools by enumerating program definition data (rules, scopes, exclusions, rewards, constraints) rather than hacktivity, rankings, or reports.

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 'à partir de son slug' makes the triggering context clear: use it when you have a program slug and need program details. However, it gives no explicit when-not-to-use guidance and names no alternatives, leaving it to the agent to infer the choice among the many sibling tools.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds that the activity is public and recent, and that availability depends on hacktivity being enabled—valuable context beyond the annotations. This helps the agent anticipate the scope of data and potential empty results.

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, direct sentence that immediately states the action and its condition. It is concise, front-loaded, and contains no filler words.

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

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

The description is too sparse to fully support calling the tool. It does not describe the response format, pagination behavior, or what happens when hacktivity is disabled. With three parameters and zero schema coverage, this is a significant gap for an agent to correctly invoke the 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?

The description provides zero information about the parameters. Schema coverage is 0%, and slug, page, and page_size are only defined by their schema constraints. The description fails to explain that slug identifies the program or how pagination works, leaving the agent with no guidance beyond the raw 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 the tool's purpose: to consult the recent public activity of a program, with the condition that hacktivity is enabled. This distinguishes it from sibling tools like get_program (which returns program details) or get_report_activity (which tracks report 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 implies a usage condition (hacktivity enabled) but does not explicitly guide when to use this tool versus alternatives, nor mention any exclusions. It provides no contrast with siblings like get_program or get_report_activity, leaving usage context implicit.

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=false, so the safety profile is covered. The description adds one behavioral nuance: rankings are not guaranteed and depend on the program publishing one. Beyond that, no details about absence handling, pagination, or data shape are disclosed.

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

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

A single sentence with no filler, front-loading the main action and resource. It is appropriately brief, though its brevity contributes to missing parameter-level guidance.

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 strong annotations and simple schema, this is minimally viable for a read-only ranking lookup. However, there is no output schema and the description does not clarify pagination behavior, ranking availability, or what data is returned, leaving notable gaps for an agent.

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

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

Schema description coverage is 0%, so the description should compensate, but it does not mention slug, page, or page_size. It only implies that the ranking belongs to a program, which loosely maps to slug, and says nothing about pagination or defaults. The parameter names are self-explanatory, which keeps this from being a 1.

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 ('Consulte') and resource ('le classement des hunters d'un programme'), and adds a precise condition: the ranking is only available when the program publishes one. This clearly distinguishes it from sibling tools like get_program or get_program_hacktivity, which serve different purposes.

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

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

The description gives an explicit usage condition: use this tool when a program publishes a ranking. It does not name alternative tools or state when not to use it, but the conditional phrasing provides clear context for selection.

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, destructiveHint false, so the safety profile is clear. The description adds one behavioral note: that tracker tokens and attachment URLs are always excluded - this is useful context that could affect an agent's expectations. However, it doesn't discuss pagination, ordering, or any rate limits.

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

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

Two sentences, concise and focused. The main purpose is front-loaded, and the exclusion is stated immediately after. No wasted words.

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 tool complexity is moderate (2 parameters, no output schema), the description is somewhat complete. However, it lacks details on the structure of the timeline, whether transitions are included by default, and any filtering options. Since there's no output schema, the agent has to infer the return format from the term 'chronologie', which is vague.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the purpose of the primary parameter, report_id, by tying it to the report timeline. The second parameter, include_available_transitions, is not mentioned, but its meaning is partially inferable from the name. Still, the description adds value by clarifying what the tool returns.

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

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

The description clearly states it returns the timeline of a hunter's report (verb+resource), and mentions an important exclusion (tracker tokens and attachment URLs). It doesn't explicitly differentiate from siblings like get_my_report or get_report, but the term 'chronologie' distinguishes it as a history/timeline tool.

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

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

The description implies usage for retrieving a report's activity timeline, but provides no explicit guidance on when to use this versus siblings like get_my_report. No exclusions or alternative tool names are mentioned.

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 annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds useful behavioral context beyond annotations: results are scoped to explicitly granted access and private programs are included, which is a meaningful guarantee for the caller.

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 sentence conveys the full meaning with no repetition or filler. The key scoping details—'explicitly has access' and 'including private programs'—are front-loaded and each phrase 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 zero-parameter filtered list tool with no output schema, the description is complete enough: it states exactly what is listed and highlights the critical inclusion of private programs. The annotations handle safety and open-world semantics, so nothing else is required to 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?

The input schema has zero parameters and 100% description coverage, so there is no parameter burden for the description to carry. The baseline of 4 applies because nothing is missing in parameter documentation.

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

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

The description clearly states a specific verb and resource: it lists programs for which the connected hunter has explicit access, including private programs. It does not explicitly differentiate itself from sibling tools like search_programs, but the 'explicit access' scope makes the distinction inferable.

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 use case is implied: call this when you need the current hunter's explicitly accessible programs, including private ones. However, there is no explicit when/when-not guidance or comparison with alternatives such as search_programs or recently_updated_programs.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior; on top of that the description adds concrete behavioral context: pagination support and a 'first version' without mutation or export. This extra context helps the agent understand current limitations without contradicting the annotations.

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

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

Two short sentences, the first stating the purpose and the second adding a useful limitation. No filler or redundant schema repetition.

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

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

For a two-optional-parameter listing endpoint with strong annotations, the description covers scope (connected hunter's reports), a behavioral limitation (no mutation/export), and pagination. It does not describe output fields, but no output schema exists and the return concept is straightforward enough for invocation.

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

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

Schema description coverage is 0%, but the description's 'pagination' mention plus the self-explanatory page and page_size names and their schema constraints make the parameters understandable. The description adds minimal semantic value beyond the schema and does not fully compensate for missing 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 concrete action and resource: 'Liste les rapports soumis par le hunter connecté' (list reports submitted by the connected hunter), which clearly identifies a read-only listing of the caller's reports. It is distinct from singular get_my_report and program-related siblings, but it does not explicitly differentiate itself from search_my_reports, so it falls short of a fully differentiating 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 pagination and no-mutation/no-export notes imply this tool is for simple paginated read access, but the description never states when to prefer it over search_my_reports, get_my_report, or my_report_status_counts. Usage is inferred rather than made 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 cover read-only, idempotent, and non-destructive behavior. The description adds a useful non-obvious guarantee: logins, emails, and passwords are never returned, which helps an agent set correct expectations about the output and avoid assuming secrets are included.

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 main purpose is front-loaded, and the redaction warning is placed second where it reinforces behavior without bloating the description.

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

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

With one required parameter, strong read-only annotations, and no output schema, the description covers what the tool does and the key output limitation. It does not detail the exact return shape or statuses of access requests, but that is not necessary 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 coverage is 0%, so the description should compensate. It ties the slug to a specific program ('d'un programme') but does not explain how to obtain the slug or provide an example. Since there is only one required parameter with a self-explanatory name, this is minimally adequate.

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

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

The description uses a specific verb ('Liste') and a unique resource ('credentials de test et demandes d'accès d'un programme'), which clearly distinguishes it from sibling tools like get_program or list_accessible_programs. The scope is per-program and the purpose is immediately understandable.

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 for listing credential-related data for a single identified program, and program_slug is required. However, it does not explicitly state when to prefer this tool over siblings or mention any 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive, covering the safety profile. The description adds no further behavioral context such as potential performance implications of aggregation, authentication requirements, or rate limits. It simply restates the content returned, which is acceptable given the annotations but adds no extra value beyond 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 a single concise sentence that front-loads the core purpose and lists the aggregated categories. There is no redundant information or filler. It is appropriately brief, though it could have included parameter hints without becoming verbose.

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 tool's complexity (aggregating multiple data types) and the absence of an output schema and parameter descriptions, the description is incomplete. It does not specify what the output structure looks like, how parameters filter results, or any limitations. An agent would struggle to call this tool correctly 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?

The input schema provides zero description coverage (0%), and the tool description does not explain any of the three parameters (start_date, end_date, program_slugs). An agent has no clue about the purpose or format of these parameters, which are entirely optional but likely affect the aggregation scope. The description fails to compensate for the schema's lack of information.

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 aggregated indicators for the hunter, listing the specific categories (reports, statuses, criticalities, rewards, credit balance). It uses a specific verb ('Retourne') and resource ('indicateurs agrégés du hunter'), which distinguishes it from sibling tools that handle individual aspects (e.g., get_my_credit_balance, list_my_reports). The aggregation concept is explicit.

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 on when to use this dashboard versus the more specific sibling tools. It does not mention that this is a summary view or that detailed operations should use dedicated tools. No exclusions or alternative recommendations are provided, leaving the agent to infer usage context from the name and description alone.

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 that the tool is read-only, idempotent, and non-destructive. The description adds useful scope ('hunter connecté' = current hunter's reports) and the aggregation by status, but it does not disclose the exact output shape or any edge cases. This is adequate but not rich.

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

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

The description is a single short French sentence with no filler. It front-loads the action, resource, scope, and grouping dimension, making every word meaningful.

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 count tool, the description covers the essential information: scope (connected hunter), resource (reports), and grouping (by status). Since there is no output schema, an explicit return-shape note would have been slightly better, but the semantics are simple enough for an agent to infer.

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

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

The input schema has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description imposes no parameter expectations. Nothing is missing 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 uses a clear verb ('Compte' = counts) with a specific resource ('rapports du hunter connecté') and a grouping dimension ('par statut'). It clearly conveys aggregation by status rather than listing, which distinguishes it from sibling list/search tools, though it does not name 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 guidance on when to use this tool versus alternatives such as list_my_reports, search_my_reports, or my_hunter_dashboard. The only implied usage is 'count reports by status,' and no exclusions or alternative routing are provided.

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, open-world, and non-destructive behavior, so the description only needs to add semantic context. It adds the 'visible' scope and interprets 'recently updated' as relating to rules or scopes, but it does not clarify visibility semantics, return shape, or pagination. 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 a single front-loaded sentence that names the action, the resource, and the purpose with no filler. Every phrase 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?

This is a simple read-only list tool with richly annotated safety properties, so the description is minimally viable; an agent can infer the basic behavior and defaults. However, it leaves parameter semantics undocumented and does not describe the result shape, which matters because no output schema is present.

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

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

Schema description coverage is 0%, and the description does not mention any of the four parameters (type, limit, search, include_disabled). It therefore adds no meaning beyond the raw property names and enum/default values, leaving the schema to carry the full burden.

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

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

The description opens with a specific verb and resource ('Liste les programmes visibles les plus récemment mis à jour') and adds a clear purpose: spotting potential rule or scope changes. It is clearly distinct from siblings like list_accessible_programs or search_programs by focusing on recency, though it does not explicitly name an alternative.

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 'afin de repérer les changements potentiels de règles ou de scopes' gives the intended use case: use this when monitoring for recent program changes. It does not, however, mention when not to use it or point to alternatives such as search_programs or list_accessible_programs.

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, so the safety profile is handled. The description adds that results are scoped to the connected hunter and enumerates filters, but it does not disclose pagination, result shape, or ordering.

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 efficient sentence that front-loads the action and resource, then lists the supported filter dimensions. There is no filler or repetition of schema constraints.

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 definition is adequate for a read-only search call: scope and main filters are present, and annotations handle side effects. It lacks explicit guidance on result format, pagination behavior, and sibling differentiation, which would make it fully self-contained.

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

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

Schema description coverage is 0%, so the prose must carry the semantic load; it maps most parameters to everyday categories: text, program, status, criticality, reward, and date range. It leaves page/page_size implicit, but the schema's names and defaults make those unambiguous.

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 ('Recherche') and resource ('rapports du hunter connecté'), and lists concrete filter dimensions. It is clear about what it does, though it does not explicitly differentiate itself from list_my_reports or get_my_report.

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 filtering language implies this is the tool to use when searching reports by text, program, status, severity, reward, or date. However, it never states when not to use it or names a preferred alternative for unfiltered listing.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a visibility scope ('visible par le hunter connecté') and pagination, which are useful, but it does not disclose any additional behavioral traits such as result ordering, filtering semantics, or rate limits.

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

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

The description is a single, front-loaded sentence with no filler or redundant information. It is appropriately concise for conveying the main purpose, though it sacrifices detail that other dimensions depend on.

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 5-parameter search tool with no output schema and 0% schema coverage, the description is too sparse to be complete. It omits parameter semantics, return value expectations, and any differentiation from sibling listing tools, so an agent would need external knowledge or trial and error to use it reliably.

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?

With 0% schema description coverage, the description carries the full burden of explaining parameters, but it only generically mentions 'search' and 'pagination.' It does not explain the meaning of `type` enum values, `include_disabled`, or what `search` matches, leaving the agent without enough information to choose parameter values correctly.

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 ('Recherche') and resource ('le catalogue de programmes visible par le hunter connecté'), clearly conveying a search-and-pagination operation. However, it does not explicitly differentiate itself from sibling tools like list_accessible_programs or recently_updated_programs, which also relate to program catalog listing.

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 guidance is provided on when to use this tool over its siblings. There is no mention of alternatives, exclusions, or typical use cases, so an agent must infer the intended usage from the name and bare description.

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?

Les annotations déclarent déjà readOnlyHint, idempotentHint et destructiveHint=false. La description ajoute une garantie comportementale précieuse : 'Ne renvoie jamais les secrets ni le jeton', et précise le mode d'authentification (identifiants + TOTP), ce qui va au-delà des annotations sans les contredire.

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?

Deux phrases courtes, informatives et sans redondance. La fonction principale est annoncée dès le début, et la phrase sur la non-divulgation des secrets est un complément important sans remplissage.

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?

L'outil est simple (aucun paramètre) et la description couvre bien l'objet de la vérification ainsi qu'une garantie de sécurité. Cependant, il n'y a pas de schéma de sortie et la description ne dit pas ce que l'outil renvoie concrètement (succès/échec, état, format), ce qui laisse une part d'inférence à l'agent.

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?

L'outil possède zéro paramètre et le schéma d'entrée est vide, donc il n'y a aucune sémantique de paramètre à documenter. La description confirme implicitement qu'il s'agit d'un appel sans entrée ; le baseline 4 pour les outils sans paramètres est respecté.

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?

La description utilise un verbe précis ('Vérifie') et nomme exactement les ressources concernées : configuration .env et authentification YesWeHack par identifiants/TOTP. Cette fonction est clairement distincte des outils frères, qui sont tous orientés programmes, rapports ou crédits, donc aucun recoupement avec session_status.

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?

Le contexte d'utilisation est limpide : c'est l'outil à appeler pour valider la configuration et l'authentification avant d'utiliser les autres outils. Aucune alternative de session n'existe parmi les frères, donc aucune exclusion n'est nécessaire, mais la description ne formule pas explicitement de règle 'quand utiliser vs quand ne pas utiliser'.

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