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

With no annotations, the description carries full responsibility. It discloses the async nature, the HTTP 202 response, the jobId result, polling via profilarr_get_job, and that the archive is sanitized (secrets stripped) — all valuable behavioral details beyond the schema.

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

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

Two concise sentences immediately state the core action and the critical async/polling behavior. Every clause adds value with no redundancy.

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

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

Despite no annotations, the description fully covers the operational flow: what it creates, the async response, how to poll, and a key security behavior. With no parameters and an output schema present, nothing needed is left out.

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 coverage is 100%, so the description has nothing to add. According to the rubric, 0 params earns a baseline of 4.

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 starts with the specific verb 'Create' and resource 'a backup', clearly distinguishing this from sibling tools like list/download/delete/upload backups. It also adds unique behavior (async, sanitized) that differentiates it further.

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

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

The description implies its usage as the creation action within the backup tool family and clearly states how to track the operation with profilarr_get_job. However, it doesn't explicitly state when not to use it or contrast with alternatives, though the context makes it evident.

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 present, so the description carries the burden for behavioral disclosure. It discloses clone/validate/process actions, synchronous execution, and token-related prerequisites, giving some useful context. However, it omits potential side effects such as repo overwrites, network dependencies, failure modes, or reversibility, which is a notable gap for a creation/linking 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?

Three compact sentences deliver the essential purpose, execution context, and a key parameter dependency without waste. Information is front-loaded: the action is stated first, then supporting details.

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?

Despite having an output schema, the description does not adequately cover the complexity of a 10-parameter creation tool. It mentions the return type and token prerequisite but ignores parameter semantics, failure scenarios, prerequisites like git availability, and relationships to other database operations. The description is not sufficient for an agent to confidently invoke the tool in varied situations.

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 10 parameters and 0% schema description coverage, the description must compensate, but it only documents the personal_access_token/git_user_name/git_user_email relationship. All other parameters (branch, auto_pull, sync_strategy, conflict_strategy, local_ops_enabled, etc.) receive no explanation, leaving most schema fields semantically opaque.

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 explains the core action: 'Link a PCD database' followed by concrete sub-steps (clones repo, validates manifest, processes dependencies). This distinguishes it from siblings like list_databases or sync_database, though 'Link' is slightly less direct than the tool name 'create_database' and PCD is not expanded.

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 explicit guidance on when to use this tool versus alternatives such as update_database or sync_database. The description provides operational context (synchronous, may take seconds) and a prerequisite relationship for personal_access_token, but does not clarify use cases, exclusions, or alternatives.

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

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

While the annotation 'destructiveHint: true' covers the destructive nature, the description adds little beyond that, only restating the location 'from the server.' It does not disclose whether deletion is permanent, reversible, or requires special permissions, leaving the agent without extra 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 sentence with no filler, front-loaded with the imperative verb 'Delete.' It is appropriately sized for a simple operation and maintains high readability.

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 sufficient for a basic delete operation, but it lacks context on how to obtain valid filenames (e.g., from list_backups) or any prerequisites. The presence of an output schema mitigates the need to explain return values, but the missing usage context makes it only minimally complete.

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

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

The description does not mention the 'filename' parameter or explain how to specify which backup to delete. With schema description coverage at 0%, the agent has no additional guidance beyond the parameter name and type, which is insufficient for understanding what values are expected.

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 'Delete a backup archive' with a specific verb and resource, distinguishing it from sibling backup operations like create, download, or list backups. It leaves no ambiguity about what the tool does.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as listing backups first or confirming the backup is no longer needed. It simply states the action without any contextual cues about appropriate 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?

The description goes well beyond the destructiveHint annotation by itemizing exactly what is destroyed: the row, the cloned repo on disk, and scheduled sync jobs. This adds valuable context about the tool's side effects and irreversible actions.

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 that is front-loaded with the verb 'Unlink' and efficiently lists all three consequences. There is no redundant or unnecessary 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 destructive tool with one parameter and an output schema, the description covers the essential behavior and side effects. The presence of the destructive annotation and output schema complements the description, making it sufficiently complete.

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

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

Schema description coverage is 0%, and the description does not explicitly explain the 'id' parameter. However, the sole parameter is an integer 'id' and the tool name plus description make it clear it refers to the database identifier. The description provides no additional detail beyond the schema, but the meaning is 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 action ('Unlink a database') and lists specific consequences (removes row, deletes cloned repo, cancels sync jobs). It distinguishes the tool from sibling operations like update_database or sync_database by specifying the destructive nature and 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 implies usage for permanently removing a database, but it does not explicitly state when to choose this over alternatives or mention any exclusions. The context is clear enough, but no explicit guidance is 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 declare readOnlyHint=true, and the description adds useful behavioral details beyond that: sanitization on the fly, writing to PROFILARR_TEMP_DIR or system temp, and returning {path, filename, size}. This enriches the agent's understanding of side effects and output.

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

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

Two sentences, front-loaded with the primary action, then the output contract. Every word earns its place with no redundancy.

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

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

The description covers the core behavior, return format, and temp location, which is sufficient for a simple download tool. It lacks explicit error handling or parameter format, but the presence of an output schema and the simplicity of the operation still makes it reasonably complete.

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

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

Schema description coverage is 0%, and the description does not explain the required 'filename' parameter. The name is somewhat self-explanatory, but the tool would benefit from clarifying whether it's the backup name from list_backups or a specific format. The description does not compensate for the lack of schema 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 tool downloads a backup archive, sanitizes it, and writes it to a temporary directory, with a specific return format. This distinguishes it from sibling tools like list_backups, create_backup, delete_backup, and upload_backup.

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 context is clear: use when you need to retrieve a backup file locally. It doesn't explicitly list alternatives or when-not-to-use, but the action is unambiguous and aligns with the tool's name and siblings.

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 readOnlyHint annotation already establishes this is a safe read operation. The description adds value by specifying that the response includes the markdown body, which is a behavioral detail beyond the annotation. No contradiction exists, and the additional context is useful.

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 of 13 words. It is front-loaded with the key action and resource, includes no fluff, and every word adds meaning.

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 get tool with one parameter and an output schema, the description is complete. It states what to retrieve and highlights the markdown body. Sibling tools provide additional context for source of ids, and the output schema covers return structure, so no significant gaps exist.

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 must compensate. It clarifies that the 'id' parameter is an announcement identifier ('by id'), but does not explain the id's origin, format, or how to obtain it (e.g., from list_announcements). This is minimal compensation, warranting a mid-range score.

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 'Get' and the resource 'a single announcement by id', explicitly distinguishing this from the sibling tool 'profilarr_list_announcements' which lists announcements. It also notes the markdown body, making the purpose specific and unambiguous.

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

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

The description implies usage: when you need a single announcement by its id. It sets clear context (id required) but does not explicitly mention when not to use it or point to alternatives like list_announcements for retrieving multiple announcements. This is acceptable but not fully 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?

The readOnlyHint annotation already declares the safe read-only nature. The description adds some context by listing the settings fields returned, but it does not disclose any additional behavioral traits such as return format, potential errors, or configuration defaults.

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, front-loaded with the action and resource, and each word adds value. No filler 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 parameterless getter with a read-only annotation and output schema available, the description sufficiently conveys the tool's purpose and key result fields. No additional 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?

There are no parameters, and the schema is fully covered (100% baseline). With zero parameters, the description does not need to explain parameter semantics, so the baseline score of 4 applies.

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

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

The description uses a specific verb+resource pattern ('Get backup settings') and explicitly names fields like schedule, retentionDays, and enabled. It clearly distinguishes the read operation from sibling tools like update_backup_settings and list_backups.

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 a read-only getter for backup settings, and the sibling update_backup_settings suggests the complementary write operation. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safe-read nature is known. The description adds 'Secrets stripped,' which is a meaningful behavioral disclosure about the response content. This goes beyond the annotation and gives insight into what the tool returns, though no error or rate-limit details are provided.

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

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

The description is two short, front-loaded sentences: 'Get a single linked database by id. Secrets stripped.' Every word adds value, and the structure is efficiently ordered with the primary action first.

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 get-by-id operation with an output schema present, the description adequately covers the core purpose and a key behavioral detail. It does not explain usage alternatives or id provenance, but given the tool's low complexity, this is nearly complete.

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

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

The input schema has a single integer 'id' with 0% schema description coverage. The description merely repeats 'by id' without explaining what the id refers to, how to obtain it, or any constraints. It does not compensate for the schema's lack of 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: 'Get a single linked database by id.' This distinguishes it from sibling tools like list_databases (which gets all) and create/update/delete, and the additional 'Secrets stripped' further specifies the tool's behavior.

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 when you have a specific id ('by id') and a single database, but it does not explicitly contrast with list_databases or mention when not to use. There is clear context but no exclusions or named alternatives.

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

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

The readOnlyHint annotation already signals a safe read operation. The description adds value by explicitly stating that the tool returns the run result once the job finishes, which gives insight into how the response evolves over time and what to expect. This is useful beyond the annotation.

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 with no wasted words. The description is front-loaded with the action and target, and the parenthetical examples are compact yet highly informative.

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 single-parameter getter with a readOnlyHint annotation and an output schema, the description fully covers what the tool does, where to obtain the ID, and the return behavior. No critical information is missing.

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

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

The schema has a single 'id' parameter with 0% description coverage, but the description compensates by linking the job-queue entry to specific operations that produce an ID. While it doesn't explicitly say 'id is the job ID', the examples make the mapping obvious for a single required integer parameter.

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 ('Get') and resource ('current status of a job-queue entry'), and references concrete sibling tools (profilarr_create_backup, profilarr_sync_database) to identify what kind of job it refers to. This distinguishes it from generic status/health tools like profilarr_status or profilarr_health.

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

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

It provides clear context for when to use this tool: after creating a backup or syncing a database, where the job ID comes from. While it doesn't explicitly mention when not to use it or name alternatives, the examples are enough to guide appropriate usage without ambiguity.

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 readOnlyHint annotation already indicates a safe read operation. The description adds the detail that the spec is 'resolved' and returned as a JSON document, which provides some behavioral context beyond the annotation. However, it does not disclose potential size or other nuances, though for a zero-parameter fetch operation this is acceptable.

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 directly states the tool's function without any redundant words. It is appropriately sized for the tool's simplicity.

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 no parameters, a read-only annotation, and an output schema, the description is sufficient. It clearly states what is fetched and the format, so the agent has all necessary context to invoke the tool correctly.

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

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

The tool has zero parameters, and the schema coverage is 100% (since there are no parameters to describe). The description does not need to elaborate on parameters. The baseline for zero-parameter tools is 4, and the description is consistent with that.

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 explicitly states the verb 'Fetch', the target resource 'Profilarr's resolved OpenAPI 3.1 spec', and the output format 'as a JSON document'. This clearly distinguishes it from sibling tools, none of which fetch the OpenAPI spec.

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

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

The description provides clear context that this tool returns the API spec, and there are no overlapping sibling tools, making its usage obvious. It does not explicitly mention alternatives or when-not-to-use, but the unique purpose makes exclusions unnecessary.

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, and the description adds that the tool is public, requires no API key, and returns a status and timestamp. This provides behavioral context beyond the annotation, such as auth requirements and return content.

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 entire description is a single concise sentence that covers purpose, auth requirements, and return format, with no redundant or unnecessary 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?

For a parameterless health-check tool with an output schema, the description covers all essential aspects: purpose, public access, no API key, and return values. It is fully sufficient for an agent to invoke 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, so the baseline of 4 applies. The description doesn't need to explain parameter meaning, and it doesn't add any parameter-related information, which 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 the tool checks system health and lists the possible status values (healthy|degraded|unhealthy) and return timestamp. It does not explicitly differentiate from the sibling 'profilarr_status', but the purpose is unambiguous.

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

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

The description mentions 'Public -- requires no API key', providing clear context that this tool can be used without authentication. It does not explicitly state when to use this over other tools, but the public access note is a useful usage guideline.

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, which the description does not contradict. The description goes beyond the annotation by explaining the filtering behavior (withdrawn/expired/version-incompatible) and sort order (newest first), providing useful context for the agent.

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 conveys the action, scope, and ordering with no wasted words. Every element adds value.

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 (zero params), the read-only annotation, and the presence of an output schema, the description sufficiently covers the essential behavior. The filtering and ordering details make it complete for its scope.

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

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

The tool has zero parameters and the schema coverage is 100% (trivially). The description does not need to explain parameters, and the baseline score of 4 applies.

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

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

The description uses the specific verb 'list' with resource 'announcements', and adds clear qualifiers: only visible ones (withdrawn/expired/version-incompatible filtered) and ordering (newest first). This distinguishes it from the sibling tool 'profilarr_get_announcement' which likely fetches a single announcement.

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 states what the tool does and implies when to use it: to get a list of visible/current announcements. However, it does not explicitly name alternatives or exclusion scenarios, though the filtering note implicitly indicates that hidden announcements would require a different tool.

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

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

The description adds a valuable behavioral disclosure: 'Secrets (api_key) are stripped.' This goes beyond the readOnlyHint annotation, informing the agent that sensitive data will be redacted from the response. This is critical for setting expectations about the returned data. 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: the primary purpose and the important secret-stripping note. It is front-loaded and contains no filler or repetition. Every word earns its place.

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

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

This is a simple read-only listing tool with no parameters, an output schema present, and annotations. The description fully covers the essential behavior: listing instances and warning about secret redaction. With the output schema providing return structure, nothing further 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 zero parameters, and the input schema is empty, so schema coverage is 100%. The description does not need to add parameter meaning. Per rubric, zero parameters warrant a baseline of 4.

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: 'List connected Radarr/Sonarr instances.' It uses a specific verb ('List') and a specific resource ('connected Radarr/Sonarr instances'). This distinguishes it from sibling tools like list_announcements or list_databases, which target different 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 stating the resource it lists, but it does not explicitly mention when to use this tool vs. alternatives or provide any exclusion criteria. Since there are several sibling list tools, the lack of explicit 'when to use' guidance leaves the agent to infer from the name and resource type.

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 declare readOnlyHint=true, so the safety profile is covered. The description adds the behavior that results are sorted newest first, which is useful. However, it does not disclose other behaviors like pagination or return structure, though an output schema exists to fill that 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, concise sentence of 10 words. It is front-loaded with the action and resource, and every word contributes meaning without redundancy.

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

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

For a simple list operation with no parameters, an output schema, and read-only annotation, the description fully captures the tool's purpose and behavior. Nothing essential is missing given the low complexity.

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

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

The tool has zero parameters, so the input schema is empty. Per the rubric, a baseline of 4 is appropriate since there are no parameter semantics to explain.

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 ('List'), the resource ('backup archives'), and the scope ('on the server'), plus ordering ('newest first'). It distinguishes itself from sibling tools like create, download, delete, and upload backup.

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 usage is implied by the verb 'List' — clearly for enumerating backups. However, it does not explicitly mention when not to use it or alternatives such as download_backup for retrieving a specific archive. Guidance is implicit rather than explicit.

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

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

The description adds the noteworthy behavior that secrets are stripped from the response (personal_access_token replaced with hasPat). This goes beyond the readOnlyHint annotation, providing valuable insight into the tool's data redaction 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 concise sentence of 11 words, front-loaded with the action and resource. Every word contributes meaning, with no fluff.

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

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

For a parameterless list operation with an output schema and readOnly annotation, the description fully covers the essential behavior. The secret-stripping note addresses the only potential surprise, making the description complete.

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

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

The tool has no parameters, so the description does not need to explain them. It adds value by clarifying the output semantics (secrets stripped), which is useful for the agent.

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 'List' and a specific resource 'linked PCD databases', clearly distinguishing from sibling tools like get_database or list_announcements. It precisely states the tool's function.

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 clarifies when to use this tool (to list all linked PCD databases) and implicitly contrasts with get_database for individual retrieval. It does not explicitly name alternatives but the context is clear.

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 readOnlyHint annotation already establishes the tool as a safe read operation. The description adds value by specifying exactly what system information is returned, such as sync states and unread announcements, giving the agent a clear picture of the tool's scope without contradicting the annotation.

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, tightly packed sentence that lists all major status components without fluff. Every word contributes to conveying what the tool does, making it maximally efficient and easy to parse.

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

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

For a parameterless, read-only status aggregation tool, the description covers all key aspects: version, uptime, databases, arrs, job queue, backups, and announcements. Since an output schema exists, the description does not need to detail return values, and no gaps are evident.

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 there is no semantic burden on the description. The baseline for parameterless tools is 4, and the description provides no unnecessary parameter explanations, which 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 'Get overall system status' and enumerates the specific components (version, uptime, databases, arrs, job queue, backups, unread announcements). This distinguishes it from sibling tools like profilarr_health or profilarr_list_announcements, which focus on individual 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 clear context by listing all the status areas covered, indicating this is a comprehensive overview tool. It does not explicitly exclude alternatives, but the "overall" framing implies it should be used when a broad status snapshot is needed rather than individual list queries.

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

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

With no annotations, the description shoulders the transparency burden. It discloses that the operation is asynchronous, returns HTTP 202 with a jobId, and that it pulls the linked database repository rather than an Arr instance. It does not mention potential side effects on existing data, but the core async behavior is clearly described.

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

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

Two sentences, no fluff. The action is stated first, followed by async behavior and a clarifying note. Every word earns its place and the structure is easy to scan.

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 covers purpose, async behavior, return format, and a common confusion (Arr sync). However, it misses the parameter meaning entirely, which is critical for correct invocation. Overall, it is adequate but has a notable gap for a tool with one parameter.

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 one required integer parameter 'id' with no description (schema coverage 0%). The description does not mention 'id' at all, leaving the agent to guess whether it refers to a database id, job id, or something else. This is a significant omission for a single-parameter tool.

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 'Trigger' and clearly identifies the resource ('database pull / PCD sync'). It also distinguishes itself from an Arr instance sync, which is a key differentiator among sibling tools.

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

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

The description explicitly states what the tool does NOT do ('NOT an Arr instance sync'), which helps avoid misuse. It also instructs to poll with profilarr_get_job(jobId) for async completion. However, it does not provide broader when-to-use context or prerequisites beyond the linked DB repo.

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

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

With no annotations, the description carries the burden. It discloses the updatable fields with allowed values and states 'Returns updated settings'. However, it doesn't mention behavior when no parameters are provided, validation, or whether this is a partial update.

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?

Three short, front-loaded sentences with the primary verb first. Each sentence adds value: purpose, constraints, and return. No filler or redundancy.

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

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

Given the simple 3-parameter optional schema and the presence of an output schema, the description covers purpose, parameter constraints, and return. It lacks explicit usage alternatives but is otherwise complete for a straightforward update 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 provides enums for schedule ('hourly|daily|weekly|monthly'), a range for retention_days ('1-365'), and names enabled, adding meaning beyond the bare schema. It doesn't fully explain the effect of each parameter, but it covers all three.

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 'Update backup settings', a specific verb+resource, and clarifies the exact updatable fields ('Only schedule ..., retention_days ..., and enabled are updatable'). This clearly distinguishes it from sibling tools like profilarr_get_backup_settings.

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 on when to use this tool versus alternatives or when it would be inappropriate (e.g., read-only contexts). The 'Only' clause is a constraint, not usage direction, and no sibling tool is 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?

With no annotations, the description must carry the full burden. It discloses key partial-update semantics ('Only provided fields change; unknown fields are ignored') and references dependency rules, which is helpful. However, it omits authorization requirements, error behavior, and whether changes are reversible, leaving significant gaps 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 two sentences, front-loaded with the core purpose, and every sentence earns its place. It efficiently includes the critical behavioral detail and a cross-reference to a related tool without any fluff.

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 an output schema and moderate complexity (dynamic patch object), the description covers the essential partial-update behavior, unknown-field handling, and dependency rules via reference. It omits error cases and id context, but the output schema covers return values, making this reasonably complete.

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

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

The input schema has no descriptions for id or patch, and schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that patch is a partial object and unknown fields are ignored, and it points to create_database for field rules. Yet it does not elaborate on the id parameter or enumerate specific patch fields, so only partial compensation is achieved.

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 'Partial update of a linked database' with a specific verb (update) and resource (database), and the 'partial' qualifier distinguishes it from full creation or deletion. It also implies a relationship to other database tools, though it doesn't explicitly name alternatives, so it falls short of a 5.

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

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

The description provides valuable context by pointing to profilarr_create_database for field-dependency rules, which helps users understand when certain patch fields are valid. However, it does not explicitly state when to use this tool versus sibling tools like sync_database or get_database, nor does it mention any exclusions or prerequisites beyond the dependency rules.

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

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

With no annotations, the description carries the full burden. It discloses the upload action, the multipart form data format, and the return value. However, it does not mention potential side effects like overwriting existing backups, authentication requirements, or error handling, which could be relevant for a mutating 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 two concise sentences, front-loaded with the core action and return value. No filler 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 simple one-parameter upload tool with an output schema, the description adequately covers what the tool does and what it returns. It lacks details like size limits or edge cases, but these are not essential for basic invocation and 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?

The schema has zero parameter descriptions, but the single 'filepath' parameter is self-explanatory given the tool name and the description's reference to a 'local .tar.gz backup'. The description effectively implies that filepath is the path to the local file, compensating for the schema gap.

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 (upload a local .tar.gz backup to the server as multipart form data) and the return value (stored filename/size). This distinguishes it from siblings like download_backup and delete_backup by focusing on the upload direction.

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 when a local backup file needs to be stored on the server, but does not explicitly mention when to use it versus alternatives like create_backup or download_backup. No exclusions or alternative references are provided.

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