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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool adds or updates an API in a monitoring catalog, implying a write/mutation operation, but doesn't clarify if this is idempotent, what happens on conflicts (e.g., duplicate aliases), whether updates are partial or full, or any side effects like triggering health checks. For a mutation tool with 11 parameters, this is insufficient.

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, efficient sentence that directly states the tool's purpose without redundancy. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, with no wasted verbiage.

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 (11 parameters, mutation operation) and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral aspects like error handling, idempotency, or return values, leaving significant gaps for an AI agent to understand how to invoke it correctly in a monitoring 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 description adds no parameter-specific information beyond what the schema provides. Since schema description coverage is 100%, the baseline score is 3. The description doesn't explain relationships between parameters (e.g., how auth_method interacts with api_key or htpasswd fields) or provide examples, so it doesn't compensate for the schema's limitations.

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 action ('Ajoute ou met à jour') and resource ('une API dans le catalogue de monitoring'), making the purpose explicit. It distinguishes from sibling tools like api_list and api_remove by focusing on addition/update rather than listing or removal. However, it doesn't explicitly differentiate from server_add or other catalog-related tools beyond the API scope.

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. It doesn't mention prerequisites (e.g., when an API should be added vs. updated), nor does it reference sibling tools like api_check or api_remove for complementary operations. Usage is implied through the action but lacks explicit 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions launching a health test but doesn't describe what the test entails, what kind of response to expect, whether it's read-only or has side effects, or any performance characteristics. This leaves significant gaps for an agent to understand the tool's 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the essential 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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the health test involves, what results to expect, or how this differs from similar tools. Given the complexity of API health checking and the lack of structured metadata, more context is needed for effective use.

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, clearly documenting both required parameters. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value like explaining parameter relationships or usage examples.

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 action ('Lance un test de santé') and target ('sur une API du catalogue'), which is specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'check_api_health' which appears to serve a similar purpose, leaving some ambiguity about tool selection.

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 like 'check_api_health' or other monitoring tools in the sibling list. It states what the tool does but offers no context about appropriate use cases 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool displays all APIs, implying a read-only operation, but doesn't specify details like whether it requires authentication, how data is formatted (e.g., pagination, sorting), or potential rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, clear sentence: 'Affiche toutes les APIs configurées dans le catalogue.' It's front-loaded with the core purpose, has no unnecessary words, and efficiently conveys the essential information without waste.

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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It states what the tool does but lacks context about usage, behavior, or output format. For a basic list tool, it meets the minimum viable standard but could be more helpful by adding details like output structure or when to use 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 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, as there are none. A baseline score of 4 is appropriate for tools with no parameters, as there's nothing to compensate for.

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: 'Affiche toutes les APIs configurées dans le catalogue' (Displays all APIs configured in the catalog). It specifies the verb 'affiche' (displays) and the resource 'APIs du catalogue' (APIs in the catalog). However, it doesn't explicitly differentiate from sibling tools like 'server_list' or 'task_history', which also list resources but different types.

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. It doesn't mention any prerequisites, context for usage, or comparisons to siblings like 'api_check' or 'api_add'. There's no indication of when this tool is appropriate or when other tools might be better suited.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a deletion operation but doesn't mention whether it's reversible, what permissions are required, what happens to dependent resources, or error conditions. 'Supprime' implies destructive action but lacks crucial safety and operational details.

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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a single-parameter tool and front-loads the core 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?

For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't explain what 'suppression' entails (permanent/temporary), what confirmation or side effects occur, or what the tool returns. The context demands more disclosure for safe agent use.

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

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

Schema description coverage is 100% with the single 'alias' parameter well-documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema, maintaining the baseline score 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 clearly states the action ('Supprime' - delete/remove) and the resource ('une API du catalogue' - an API from the catalog), making the purpose unambiguous. However, it doesn't differentiate from sibling 'server_remove' which removes servers rather than APIs, missing explicit sibling distinction.

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 about when to use this tool versus alternatives like 'api_check' or 'server_remove'. The description only states what the tool does without context about prerequisites, timing, 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?

With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, what permissions are needed, if it makes network calls, what happens on failure, or typical response formats. For a tool that likely performs external HTTP requests, this is a significant gap.

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

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

The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple monitoring tool and front-loads the essential information.

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

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

For a simple health-check tool with 2 parameters and no output schema, the description covers the basic purpose adequately. However, without annotations or output schema, it should ideally provide more behavioral context about what 'disponibilité' and 'temps de réponse' mean in practice and what the tool returns.

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 thoroughly. The description adds no additional meaning about parameters beyond implying they're used for testing an endpoint. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('vérifie la disponibilité et le temps de réponse') and identifies the resource ('un endpoint HTTP/S'). It distinguishes from siblings like 'api_check' by specifying health monitoring aspects rather than generic checking, though not explicitly contrasting 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?

The description provides no guidance on when to use this tool versus alternatives like 'api_check' or 'get_services_status'. It lacks context about prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from the purpose 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states it retrieves logs but doesn't mention important behaviors: whether this requires specific Docker permissions, if it streams or returns static output, potential rate limits, error conditions (e.g., if container doesn't exist), or what format the logs are returned in. For a tool with 5 parameters and no annotation coverage, this is insufficient.

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 extremely concise - a single sentence that gets straight to the point. It's front-loaded with the core purpose and wastes no words. Every word earns its place, making it easy for an AI agent to quickly understand what the tool does.

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 has 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address what the tool returns (log format, structure), error conditions, authentication requirements, or performance characteristics. For a Docker log retrieval tool that likely interacts with live containers, this leaves significant gaps in understanding how to use it effectively.

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

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

The schema has 100% description coverage, so all parameters are documented in the structured schema. The description adds no additional parameter information beyond what's already in the schema descriptions. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the 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 clearly states the verb ('récupérer' - retrieve) and resource ('logs d'un container Docker'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'get_pm2_logs' and 'tail_file' by specifying Docker containers. However, it doesn't fully differentiate from 'task_logs' which might also retrieve logs, though for tasks rather than containers.

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. It doesn't mention when to choose this over 'get_pm2_logs' for PM2 logs, 'tail_file' for general file tailing, or 'task_logs' for task-related logs. The word 'raccourci' (shortcut) hints at convenience but doesn't specify what it's a shortcut for or when it's appropriate.

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

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

No annotations are provided, so the description carries the full burden. It states it retrieves information, implying a read-only operation, but doesn't disclose behavioral traits such as whether it requires specific permissions, potential rate limits, error conditions, or the format of returned data. The description is minimal and lacks context beyond the basic action.

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, efficient sentence that front-loads the purpose and includes key usage details. There is no wasted language, and it effectively communicates the tool's scope in a compact 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?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter intent but lacks details on behavior, output format, or integration with sibling tools. For a monitoring tool with no annotations, more context would be beneficial.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters (alias and jail). The description adds marginal value by clarifying that leaving jail empty gives a general status, but doesn't provide additional semantics beyond what the schema already covers, such as examples of jail names or alias usage.

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

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

The description clearly states the verb 'Récupère' (retrieves) and the resource 'informations du service Fail2Ban', specifying it can be for all jails or a specific one. It distinguishes from siblings like get_services_status by focusing on Fail2Ban, but doesn't explicitly contrast with other monitoring tools like get_docker_logs or get_system_resources.

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 by mentioning 'pour toutes les jails ou une jail spécifique' (for all jails or a specific jail), which suggests when to use the jail parameter. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like get_services_status or other monitoring siblings, nor does it mention prerequisites or exclusions.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'récupérer' implies a read operation, it doesn't address permission requirements, rate limits, output format, or potential side effects. The description adds minimal behavioral context beyond the basic operation.

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, efficient sentence that directly states the tool's purpose. It's appropriately sized and front-loaded with the core functionality, with zero wasted words or unnecessary 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?

For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the logs contain, their format, whether they're real-time or historical, or any constraints on retrieval. The description leaves too many contextual gaps for effective agent usage.

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

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

Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description mentions retrieving logs for 'une application spécifique ou de toutes les apps' which aligns with the 'app' parameter's optional nature, but adds no additional semantic context beyond what the schema already provides.

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

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

The description clearly states the verb ('récupérer' - retrieve) and resource ('logs PM2'), specifying it can target a specific application or all applications. However, it doesn't explicitly differentiate from sibling tools like 'get_docker_logs' or 'tail_file' beyond mentioning PM2 specifically.

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. It doesn't mention when PM2 logs would be needed over other log tools like 'get_docker_logs' or 'tail_file', nor does it specify prerequisites or exclusions for usage.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether this requires specific permissions, what format the status information returns, whether it's a real-time check or cached data, potential rate limits, or error conditions. The description is minimal and lacks operational context.

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

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

The description is a single, efficient sentence that clearly states the tool's purpose. Every word contributes to understanding what the tool does without any redundancy or unnecessary elaboration. It's appropriately sized for a simple status retrieval tool.

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

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

For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the return value looks like (structured data, plain text, success/failure indicators), doesn't mention error handling, and provides no context about the operational environment. Given the complexity of checking multiple service types across different technologies, more completeness is needed.

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

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

Schema description coverage is 100% with the single parameter 'alias' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in 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 clearly states the verb ('Récupère' - retrieves) and resource ('le statut de tous les services connus') with specific service types listed (systemd, Docker, PM2). It distinguishes from siblings like get_docker_logs or get_pm2_logs by focusing on status rather than logs. However, it doesn't explicitly differentiate from get_system_resources which might overlap conceptually.

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 about when to use this tool versus alternatives. While the description implies it's for checking service status, it doesn't specify when to choose this over other monitoring tools like check_api_health or task_status, nor does it mention any prerequisites or constraints for usage.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves metrics, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns real-time or historical data, or what format the output takes. For a tool with no annotations, this leaves significant gaps in understanding its 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It front-loads the key action ('Récupère') and specifies the metrics clearly. Every part of the sentence contributes essential information, making it highly concise and well-structured.

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

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

Given the tool's complexity (simple retrieval with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers what metrics are retrieved but lacks details on output format, error handling, or behavioral constraints. For a tool with no structured support beyond the input schema, it meets basic needs but leaves room for improvement in completeness.

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

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

The input schema has 100% description coverage, with the single parameter 'alias' documented as 'Alias du serveur cible.' (Alias of the target server). The description doesn't add any semantic details beyond this, such as examples of valid aliases or how to obtain them. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

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

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

The description clearly states the verb 'Récupère' (retrieves) and the resource 'métriques système vitales (CPU, RAM, Disque) d'un serveur' (vital system metrics of a server). It specifies what metrics are retrieved (CPU, RAM, disk), making the purpose clear. However, it doesn't explicitly differentiate from sibling tools like 'get_services_status' or 'get_fail2ban_status', which might also retrieve system information but for different aspects.

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. It doesn't mention prerequisites, context for usage, or compare it to sibling tools like 'get_services_status' or 'pool_stats', which might overlap in monitoring system resources. Without such guidance, the agent must infer usage based on tool names 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a display/read operation but doesn't mention important behavioral aspects like whether it requires specific permissions, what format the statistics are returned in, if there are rate limits, or if the data is real-time versus cached. For a stats tool with zero annotation coverage, this is insufficient.

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, efficient sentence in French that directly states what the tool does. It's appropriately sized for a simple tool with no parameters and gets straight to the point without any unnecessary 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?

Given the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally adequate. It tells you what the tool does but doesn't provide enough context about what statistics are returned, their format, or behavioral considerations. For a stats tool with no output schema, more information about the return value would be helpful.

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 input schema has 100% description coverage (though empty). The description appropriately doesn't waste space discussing parameters that don't exist. A baseline of 4 is appropriate for zero-parameter tools where the schema fully documents the absence of inputs.

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

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

The description clearly states the verb ('Affiche' meaning 'Displays') and resource ('statistiques du pool de connexions SSH persistantes'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'queue_stats' or 'get_system_resources' that also provide statistical information, which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools that provide various statistics (e.g., 'queue_stats', 'get_system_resources', 'get_services_status'), but the description doesn't indicate when SSH connection pool statistics are specifically needed or when other tools might be more appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Affiche' (displays) implies a read-only operation, it doesn't specify whether this requires authentication, what format the statistics are returned in, if there are rate limits, or if the data is real-time versus cached. For a stats tool with zero annotation coverage, this is insufficient.

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, efficient sentence that gets straight to the point with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a no-parameter tool that displays statistics.

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 stats-display tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'detailed statistics' includes, the format of the output, whether this is a real-time snapshot, or any behavioral characteristics. Given the complexity of queue statistics and lack of structured documentation, more context is needed.

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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't discuss parameters since none exist, maintaining focus on what the tool does rather than what it accepts.

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 action ('Affiche' - displays/shows) and the resource ('statistiques détaillées de la queue de tâches' - detailed statistics of the task queue), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'task_queue' or 'pool_stats', but the specificity of 'detailed statistics' provides some implicit distinction.

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 like 'task_queue' or 'pool_stats'. There's no mention of prerequisites, timing considerations, or comparative context with other queue/task-related tools in the sibling list.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('enregistre ou met à jour') but doesn't cover critical aspects like authentication requirements, whether changes are reversible, potential side effects, or error handling. This is inadequate for a tool that modifies server data.

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, efficient sentence that directly states the tool's function and key requirement without any wasted words. It is appropriately sized and front-loaded with essential 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?

Given the complexity of a server configuration tool with no annotations and no output schema, the description is insufficient. It lacks details on what 'informations de connexion' includes, how updates are handled, what happens on success/failure, and how this interacts with sibling tools, leaving the agent under-informed.

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 0 parameters with 100% coverage, so the baseline is 4. The description adds value by specifying that either a key path or password must be provided, which clarifies the expected inputs beyond the empty schema, earning a slight boost.

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

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

The description clearly states the verb ('enregistre ou met à jour') and resource ('informations de connexion d'un serveur'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'server_list' or 'server_remove', which would be needed for a perfect score.

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

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

The description provides minimal guidance by mentioning 'soit un chemin de clé, soit un mot de passe', but it doesn't explain when to use this tool versus alternatives like 'server_remove' or 'api_add', nor does it specify prerequisites or exclusions. This leaves significant gaps in usage 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?

No annotations are provided, so the description carries the full burden. It states this is a display/list operation, which implies read-only behavior, but doesn't explicitly confirm it's non-destructive or safe. It mentions 'with their details' but doesn't specify what those details include or how the data is formatted/presented. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

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, clear sentence that efficiently conveys the core purpose. It's appropriately sized for a simple list tool with no parameters, with no wasted words or unnecessary 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?

For a simple list tool with no parameters and no output schema, the description is minimally adequate. It states what the tool does but lacks details about output format, behavioral characteristics, or differentiation from siblings. With no annotations to provide safety/behavior context, the description should do more to compensate, but it meets the basic threshold.

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 0 parameters, and schema description coverage is 100% (though empty). The description appropriately doesn't discuss parameters since none exist. It would score 5 if it explicitly stated 'no parameters required' or similar, but the absence of parameter discussion is correct for this case.

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

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

The description clearly states the tool's purpose: 'Affiche la liste de tous les alias de serveurs configurés avec leurs détails' (Displays the list of all configured server aliases with their details). It specifies the verb (displays/list) and resource (server aliases), but doesn't explicitly distinguish it from sibling tools like 'server_add' or 'server_remove' beyond the inherent list vs. add/remove distinction.

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. It doesn't mention prerequisites, when this tool is appropriate, or what other tools might be used instead for related operations. Given the sibling tools include both 'server_add' and 'server_remove', some basic differentiation would be helpful.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a destructive action ('Supprime'), but lacks details on permissions needed, reversibility, error handling, or system impact. This is a significant gap for a mutation tool.

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

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

The description is a single, efficient sentence with zero waste, clearly front-loading the core action. It's appropriately sized for a simple tool with one parameter.

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 destructive nature, no annotations, and no output schema, the description is incomplete. It fails to address critical aspects like confirmation prompts, return values, or error scenarios, leaving gaps for safe agent operation.

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

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

Schema description coverage is 100%, so the parameter 'alias' is well-documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, resulting in a baseline score of 3.

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

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

The description clearly states the verb ('Supprime') and resource ('un alias de serveur de la configuration'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'server_add' or 'api_remove', which would require 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 provided on when to use this tool versus alternatives like 'server_add' or 'api_remove', nor are prerequisites or exclusions mentioned. The description only states what it does, not when to apply 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?

With no annotations provided, the description carries full burden. It states the read-only nature through 'afficher' (display) and implies remote execution via 'distant' (remote). However, it doesn't disclose authentication requirements, rate limits, error conditions, or what happens with non-existent files. For a remote file access tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that immediately conveys the core functionality. Every word earns its place: establishes the Unix equivalent, specifies the operation, and clarifies it's for remote files. No wasted words or redundant 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 3-parameter tool with no annotations and no output schema, the description provides adequate basic purpose but lacks important context. It doesn't explain return format, error handling, or authentication requirements. The Unix analogy helps, but more behavioral context would be needed for complete understanding of this remote file access tool.

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

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

Schema description coverage is 100%, providing complete parameter documentation. The description adds minimal value beyond the schema - it implies 'lines' parameter functionality through 'tail -n' analogy but doesn't elaborate on parameter interactions or constraints. With full schema coverage, baseline 3 is appropriate as the description doesn't significantly enhance parameter understanding.

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

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

The description clearly states the tool's function with a specific verb ('afficher' - display/show) and resource ('dernières lignes d'un fichier distant' - last lines of a remote file). It distinguishes from siblings by focusing on file tailing rather than API management, Docker logs, or task execution. The Unix command analogy ('tail -n') provides immediate recognition.

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 context through 'fichier distant' (remote file) and the Unix analogy, suggesting this is for viewing remote server logs. However, it doesn't explicitly state when to use this versus alternatives like get_docker_logs or get_pm2_logs, nor does it mention prerequisites or exclusions. Usage is implied rather than explicitly guided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important execution behavior (30-second threshold determining synchronous vs. asynchronous operation) and mentions background processing. However, it doesn't cover other critical aspects like authentication requirements, error handling, rate limits, or what 'background' execution entails for result retrieval.

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 extremely concise (two sentences) with zero wasted words. It's front-loaded with the core purpose and immediately follows with critical behavioral information. Every sentence earns its place by providing essential operational context.

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

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

For a tool with no annotations and no output schema, the description provides basic operational context but leaves significant gaps. It doesn't explain how to retrieve results from background tasks, what the output format looks like, error conditions, or security implications. The 30-second threshold is helpful, but more completeness is needed for a remote execution 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?

With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, nor does it explain relationships between parameters. The baseline score of 3 reflects adequate but not enhanced 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 the specific action ('Exécute une commande SSH') and resource (remote server via SSH), distinguishing it from sibling tools like task_exec_interactive or task_exec_sequence. It provides precise operational details about execution timing that further differentiate its purpose.

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 context by specifying the 30-second threshold for direct vs. background execution, which helps determine when this tool is appropriate. However, it doesn't explicitly state when to use this versus alternatives like task_exec_interactive or task_exec_sequence, nor does it provide exclusion criteria.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions interactive prompt handling but lacks critical details: whether this executes commands remotely via SSH, what permissions are required, if it's read-only or destructive, error handling, or output format. For a tool with 7 parameters and no annotations, this is insufficient behavioral context.

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

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

The description is extremely concise - a single sentence that efficiently communicates the core functionality. It's front-loaded with the main purpose and includes a helpful parenthetical example of prompt types. Every word earns its place with zero 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 complex SSH execution tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how SSH connections are established, authentication requirements, error conditions, or how it differs from sibling tools. The single-sentence description is insufficient for the tool's complexity and lack of supporting structured 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 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. It mentions interactive prompts generally, which relates to parameters like 'interactive', 'autoRespond', and 'responses', but provides no additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Exécute une commande SSH avec gestion des prompts interactifs'. It specifies the verb ('exécute'), resource ('commande SSH'), and key capability ('gestion des prompts interactifs'). However, it doesn't explicitly differentiate from sibling tools like 'task_exec' or 'task_exec_sequence', which likely have related functionality.

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 minimal usage guidance. It mentions handling interactive prompts (yes/no, passwords, etc.), which implies use cases requiring user interaction, but doesn't specify when to choose this tool over alternatives like 'task_exec' or 'task_exec_sequence'. No explicit when-not-to-use scenarios or prerequisites 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions sequential execution on the same server, it lacks critical details: whether commands run with specific permissions, if there are timeouts or rate limits, what happens on errors beyond the 'continueOnError' parameter, or what the output format looks like. For a tool that executes potentially destructive SSH commands, this is a significant gap in safety and operational context.

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

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

The description is a single, clear sentence: 'Exécute plusieurs commandes SSH en séquence sur le même serveur.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence earns its place by specifying key aspects (multiple commands, SSH, sequential, same server).

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 (executing SSH commands, which can be destructive) and the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral traits like error handling, security implications, or output format, leaving the agent with insufficient context to use the tool safely and effectively. The high schema coverage helps with parameters, but overall completeness is poor for a command-execution tool.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters ('alias', 'commands', 'continueOnError', 'rappel') with descriptions. The tool description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter interactions, provide examples, or clarify ambiguous terms like 'rappel' (which might mean 'reminder' or 'timeout' in context). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Exécute plusieurs commandes SSH en séquence sur le même serveur' (Execute multiple SSH commands in sequence on the same server). It specifies the verb ('exécute'), resource ('commandes SSH'), and scope ('en séquence sur le même serveur'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'task_exec' or 'task_exec_interactive', which likely have related but different functionality.

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. It doesn't mention sibling tools like 'task_exec' (which might execute single commands) or 'task_exec_interactive' (which might provide interactive sessions), nor does it specify prerequisites, constraints, or typical use cases. The agent must infer usage 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?

No annotations are provided, so the description carries the full burden. It states this is a display/show operation, implying read-only behavior, but doesn't disclose important behavioral aspects like whether this shows all tasks or only recent ones, pagination behavior, format of returned data, or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.

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 extremely concise - just two short sentences that get straight to the point. Every word earns its place: the first sentence states the core purpose, the second adds the filtering capability. No wasted words or unnecessary 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?

Given no annotations, no output schema, and a single parameter with good schema coverage, the description is incomplete. It doesn't explain what 'latest tasks' means (time range? count limit?), what information is displayed about each task, or how the results are structured. For a task history tool that presumably returns multiple task records, more context about the return format would be helpful.

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 mentions the single parameter: 'Peut être filtré par alias' (Can be filtered by alias). The input schema has 100% description coverage, with the alias parameter fully documented. The description adds minimal value beyond what's already in the schema, so the baseline score of 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 what the tool does: 'Affiche les dernières tâches lancées' (Displays the latest launched tasks). It specifies the verb (display/show) and resource (tasks), but doesn't explicitly distinguish it from sibling tools like task_logs or task_status, which likely provide different views of task information.

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 minimal guidance: 'Peut être filtré par alias' (Can be filtered by alias). It doesn't explain when to use this tool versus alternatives like task_logs (which might show detailed logs) or task_status (which might show current status). No explicit when/when-not guidance or alternative recommendations 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool displays logs but doesn't mention whether this is a read-only operation, if it requires special permissions, how logs are retrieved (e.g., real-time vs. historical), or any rate limits. For a log-viewing tool with zero annotation coverage, this is a significant gap in behavioral context.

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

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

The description is a single, efficient sentence in French that directly states the tool's function. It's appropriately sized and front-loaded with the core purpose. However, it could be more structured by including key details like scope or differentiation.

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 complexity of a log-viewing tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the logs contain, their format, how they're sorted, or any limitations. With multiple similar siblings, more context is needed to guide proper tool selection.

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

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

Schema description coverage is 100%, with all three parameters (level, search, limit) well-documented in the schema. The description doesn't add any parameter semantics beyond what the schema provides—it doesn't explain how filtering works, what the search covers, or default behaviors. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description 'Affiche les logs du système MCP' states the tool displays MCP system logs, which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like get_docker_logs, get_pm2_logs, or tail_file, which also appear to handle logs. The purpose is understandable but lacks sibling distinction.

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. With multiple log-related siblings (get_docker_logs, get_pm2_logs, tail_file), there's no indication of what makes this tool unique or when it should be preferred. No exclusions or prerequisites 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'avec des rappels pour les tâches longues' (with reminders for long tasks), which adds some behavioral context about handling long-running tasks. However, it lacks details on output format, pagination, real-time updates, or error conditions, leaving significant gaps for a tool that likely returns dynamic data.

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, efficient sentence in French that directly states the tool's function. It's front-loaded with the core purpose and adds a brief behavioral note, with no wasted words or redundant 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?

Given the complexity of task queue monitoring and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'statut' includes (e.g., pending, running, failed), how reminders for long tasks work, or the return structure, leaving the agent with insufficient context for effective use.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for 0 parameters is 4, as it avoids unnecessary details.

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: 'Affiche le statut de toutes les tâches' (Displays the status of all tasks) with the specific verb 'affiche' (displays) and resource 'tâches' (tasks). It distinguishes from siblings like 'task_status' (which likely shows status of a single task) by specifying 'toutes' (all), but doesn't explicitly contrast with 'queue_stats' (which might show queue metrics rather than task 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'task_queue' over 'task_status' (for individual tasks), 'task_history' (for past tasks), or 'queue_stats' (for queue metrics), nor does it specify any prerequisites or exclusions for usage.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action (retry/restart) but doesn't describe what happens during retry: whether it preserves original parameters, creates a new task ID, has side effects, requires specific permissions, or what the expected outcome is. For a mutation tool with zero annotation coverage, this is insufficient.

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, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for this simple tool and front-loads the essential 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens to the original task, whether retry preserves configurations, or potential side effects. Given the complexity of task management and lack of structured data, the description should provide more operational 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% with the single parameter 'id' well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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

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

The description clearly states the verb ('relance' meaning retry/restart) and the resource ('une tâche qui a échoué ou crashé' meaning a failed or crashed task). It distinguishes from siblings like task_exec (execute new task) and task_history (view history), but doesn't explicitly contrast with them. The purpose is specific but lacks explicit 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 provides minimal guidance - it implies this tool should be used for failed/crashed tasks, but doesn't specify when NOT to use it (e.g., for successful tasks) or mention alternatives like task_exec for new executions. No explicit usage context or prerequisites 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?

With no annotations provided, the description carries full burden but only mentions 'avec un rappel si nécessaire' as behavioral context. It lacks details on permissions, rate limits, error handling, or what 'rappel' entails (e.g., notification type). This is insufficient for a tool with potential side effects like reminders.

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, efficient sentence that front-loads the core purpose. However, the vague phrase 'avec un rappel si nécessaire' adds minimal value and could be more precise, slightly reducing conciseness.

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 no annotations and no output schema, the description is incomplete. It doesn't explain what details are returned (e.g., status, metadata) or the reminder mechanism, leaving significant gaps for a tool that retrieves task details and potentially triggers reminders.

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

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

Schema description coverage is 100%, with the single parameter 'id' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 without compensating value.

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

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

The description clearly states the verb ('Récupère' - retrieves) and resource ('détails d'une seule tâche' - details of a single task), making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'task_history' or 'task_logs' which might also retrieve task-related information, preventing a perfect score.

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

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

The description provides minimal guidance with 'avec un rappel si nécessaire' (with a reminder if necessary), which hints at optional behavior but doesn't clarify when to use this tool versus alternatives like 'task_history' or 'task_logs'. No explicit when/when-not rules or sibling comparisons are included.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the 30-second threshold for direct vs. background execution and the task-based nature of the operation. However, it lacks details on error handling, authentication requirements, 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 extremely concise—two sentences that efficiently convey the core functionality and execution behavior. Every word earns its place, with no redundant or vague phrasing, making it easy to parse and understand 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 complexity of an SFTP transfer tool with 5 parameters and no output schema, the description is minimally adequate. It covers the basic operation and execution mode but lacks details on return values, error conditions, or advanced usage scenarios, leaving gaps for an AI 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?

Schema description coverage is 80%, providing a solid baseline. The description adds no additional parameter semantics beyond what the schema already documents (e.g., alias for target server, direction with enum values). It does not explain parameter interactions or usage examples, so it meets but does not exceed the baseline.

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 specific action ('Lance un transfert SFTP') and resource ('un fichier ou dossier'), distinguishing it from sibling tools like task_exec or task_transfer_multi. It precisely defines what the tool does without being tautological.

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 SFTP file transfers but provides no explicit guidance on when to use this tool versus alternatives like task_transfer_multi. No prerequisites, exclusions, or comparisons to sibling tools are mentioned, leaving usage context incomplete.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions glob pattern support which is useful, but doesn't describe critical behaviors: whether transfers are synchronous/asynchronous, error handling, authentication requirements, rate limits, or what happens when transfers fail. For a file transfer tool with mutation capabilities, this leaves significant gaps in understanding how the tool behaves.

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, efficient French sentence that communicates the core functionality without waste. It's appropriately sized and front-loaded with the essential information about what the tool does.

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 file transfer tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, how to monitor transfer progress, error conditions, or authentication requirements. The combination of mutation capability (file transfers), multiple parameters, and lack of structured metadata means the description should provide more operational 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 75%, so the schema documents most parameters well. The description adds minimal value beyond the schema - it mentions glob pattern support which relates to the 'local' parameter's pattern capability, but doesn't explain parameter interactions or provide additional context about how parameters work together. The baseline of 3 is appropriate given the decent 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 clearly states the tool's purpose: 'Lance des transferts SFTP multiples avec support de patterns glob' (Launches multiple SFTP transfers with glob pattern support). It specifies the action (launch transfers), resource (SFTP files/folders), and key capability (glob patterns). However, it doesn't explicitly differentiate from its sibling 'task_transfer' which appears to be a similar single-transfer 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'task_transfer' tool or explain when to choose multiple transfers over single transfers. There's no context about prerequisites, dependencies, or typical use cases for batch SFTP operations.

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