pbs-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation5/5
Each tool has a distinct target: task status/log/list/stop, GC run/status, datastore list/status, snapshot list/protect/forget, verify list/run, prune dry-run/apply, and health overview. No two tools overlap in purpose.
Naming Consistency4/5
The pbs_ prefix is consistent and most tools follow verb_noun (list_datastores, run_verify, protect_snapshot). A few deviations exist (pbs_datastore_status, pbs_gc_status, pbs_health_overview) but they remain clear and readable.
Tool Count5/5
17 tools covers the main PBS domains (datastores, snapshots, tasks, GC, verify, prune, health) without redundancy or bloat. Each tool serves a real administrative need.
Completeness4/5
The set thoroughly covers monitoring and maintenance operations, including dry-run for prune and a health overview. It lacks datastore/group creation/deletion, but those are arguably out of scope for an admin tool, and the core lifecycle of snapshots (list, protect, forget) is present.
Average 4.2/5 across 17 of 17 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 24 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so safety is clear. The description adds that it returns bytes information, but no further behavioral context such as authentication needs, rate limits, or side effects. This is adequate but not enriched beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded with the key output metrics. Every word earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple read-only status check with good annotations and an output schema, the description is minimally adequate. However, it lacks any context about when to use it versus pbs_list_datastores or pbs_gc_status, and it does not mention how the datastore parameter relates to the default datastore, which the schema does cover but the description could reinforce.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description carries the burden of explaining parameters, but it does not mention the 'datastore' parameter at all. The only hint is 'one datastore,' which is too vague to help an agent understand how to provide the parameter or that omitting it uses a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns: 'Total / used / available bytes for one datastore.' This is specific about the resource (datastore) and the metrics, distinguishing it from sibling tools like pbs_list_datastores which likely just list available datastores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description simply states what it does without any context about selecting a datastore or when this status check is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is well-covered. The description adds scoping ('last' statistics) and the specific statistics returned, but does not disclose additional behavioral traits like potential delays or the meaning of null datastore. This matches the get_calls calibration example where annotations carried the safety burden, scoring 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource, and then enumerates the exact statistics. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple read operation with a comprehensive output schema, the description, schema, and annotations together provide a fairly complete picture. The missing usage guidance and parameter explanation are gaps, but the core behavior is clear. The existence of an output schema means return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention the 'datastore' parameter at all. The schema provides only the name and default (null), leaving ambiguity about what datastore means or what happens when omitted. This is a significant gap, though the single optional parameter is relatively self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and identifies the exact resource ('last garbage-collection statistics') plus the specific data points (bytes referenced, pending, removed, flagged-bad chunks). This clearly distinguishes it from sibling tools like pbs_run_gc or pbs_datastore_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 is no mention of exclusions, prerequisites, or comparison with pbs_run_gc or pbs_prune. Usage context is only implied by the tool name and read-only annotations, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe, non-destructive nature is covered. The description adds useful context by explicitly using 'Preview' and 'would be kept or dropped', reinforcing that no changes are made. It does not disclose additional behavior like output format or rate limits, but the annotations carry the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the action ('Preview') and resource ('snapshots'). Every word adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity with multiple retention policy parameters, but an output schema exists so return values do not need to be described. The description is sufficient for an agent to know what the tool does and when to invoke it, though it does not elaborate on parameter interactions or prerequisites beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (only backup_id and backup_type have descriptions). The description only mentions 'retention policy' generically and does not explain the keep_* parameters (keep_last, keep_daily, etc.) that are essential for configuring the policy. The description 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Preview') and resource ('snapshots in a backup group'), and explains the purpose ('would be kept or dropped by a given retention policy'). This differentiates it from the sibling tool 'pbs_prune', which likely performs the actual pruning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to preview retention policy effects before actually pruning, but it does not explicitly state when to use it over 'pbs_prune' or provide any alternative/exclusion guidance. Usage is implied rather than clearly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral detail that exit status is returned only if the task is finished, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, with zero wasted words. It conveys the core purpose and key output detail efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-described parameter, an output schema, and strong annotations, the description is mostly complete. It could explicitly mention that a UPID is required, but the schema covers this, and the description covers the core return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter `upid` has a comprehensive schema description including format and provenance ('Full UPID string as returned by run_gc / run_verify / prune. Format: ...'). The tool description adds no parameter info, but the schema does the heavy lifting, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and precise resource ('current state of a PBS task') with details ('running / stopped' plus 'exit status if finished'). It clearly distinguishes from sibling tools like pbs_get_task_log (logs) and pbs_list_tasks (listing tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to check the state and exit status of a specific PBS task. It does not explicitly mention alternatives or exclusions, but the specificity implies when it's appropriate versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and non-read-only. The description adds valuable context: the deletion is permanent, on-disk chunks are freed only during garbage collection, and a confirmation flag is required. This goes beyond the annotation hints and clarifies the post-deletion behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the primary action. Every word earns its place. The requirement statement is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential facts for a destructive operation: permanence, garbage collection timing, and prerequisites. Output schema exists so return values are not needed. It does not mention how to obtain backup_time (though the schema includes a format example), but for a simple one-snapshot delete, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation for most parameters (backup_type, backup_id, backup_time, datastore, reason). It only repeats that confirm=true is required, which is already stated in the schema. With 0% schema description coverage, the description was expected to compensate, but it does not. The inline schema descriptions partially mitigate this, but the tool description itself adds no parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Permanently delete one snapshot', which clearly states the verb (delete), the resource (one snapshot), and the permanence. It distinguishes this tool from siblings like pbs_prune (which deletes multiple snapshots per policy) and pbs_protect_snapshot (which prevents deletion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is for deleting a single snapshot and lists prerequisites (PBS_ALLOW_WRITE=true, confirm=true). While it does not explicitly name alternatives or contrast with pbs_prune, the 'one snapshot' phrasing makes the use case clear. It could improve by explicitly saying 'Use this for deleting a single snapshot, not for bulk pruning.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context by noting that groups with zero files are flagged as likely corrupt, which is a meaningful behavioral detail beyond annotation data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear front-loaded verb and resource. Every word adds value, and the structure is extremely efficient—no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description covers purpose, scope, and a key behavioral quirk. An output schema exists so return values are already specified; the main missing piece is detailed datastore parameter semantics, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only mentions 'on a datastore' without explaining the datastore parameter's semantics. It does not clarify whether the parameter is required, what a null value means, or how it affects the results. This leaves a notable gap for the sole parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('backup groups'), specifies the scope ('on a datastore'), and mentions the key fields returned (snapshot count, last-backup time, owner, file count). It clearly distinguishes from sibling tools like pbs_list_snapshots and pbs_list_datastores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to list all backup groups on a datastore. It does not explicitly state when not to use it or name alternatives, but the purpose is unambiguous enough for a list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral context beyond the destructiveHint annotation by explaining that on-disk chunks are not freed until the next garbage collection. It also discloses environment requirements and the confirm flag, supplementing the annotation without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each providing distinct value: the main action, the GC consequence, and the usage prerequisite. No redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential safety context for a destructive tool: dry-run prerequisite, confirm requirement, and deferred space reclamation. While it does not detail all retention parameters, that gap is more about parameter semantics than overall completeness, and the presence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (per signals), and the description does not compensate by explaining the keep_* parameters or the role of each retention option. It only mentions confirm as a requirement and 'retention policy' generically, leaving most parameters under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a retention policy and drops matching snapshots, using specific verbs and resources. It distinguishes itself from pbs_prune_dry_run and other snapshot tools by indicating the actual deletion action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to always run pbs_prune_dry_run first provides a clear alternative and usage sequence. It also lists required prerequisites (PBS_ALLOW_WRITE=true and confirm=true), though it does not mention other alternatives like pbs_forget_snapshot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so no extra safety context is needed. The description adds detail about the output content (path, scheduled jobs) but does not disclose other behavioral traits such as potential for large responses or pagination. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It states the action, the resource, and the two key details (path, scheduled jobs) in under 20 words, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple read-only list with no parameters and an output schema, the description is adequate. It does not explain the return structure (but the output schema covers that) or edge cases (e.g., no datastores configured), which are minor gaps for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines no actual parameters (empty ListDatastoresInput object). With zero parameters, the baseline is 4, and the description correctly adds no parameter explanations. The required 'params' wrapper is a structural artifact but not a semantic parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('List every configured PBS datastore') and adds the precise scope ('every', 'with its path and any scheduled GC/prune jobs'). This clearly distinguishes it from siblings like pbs_datastore_status or pbs_list_snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: whenever you need an overview of all configured datastores, including paths and scheduled GC/prune jobs. It does not mention alternatives or exclusions, but the context is clear enough for an AI agent to select it appropriately among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds observable behavior beyond the annotations: results are 'newest first, capped at limit' and summary mode returns 'one aggregate row per group'. It also reveals output fields like 'protected flag' and 'last verify state', enriching the read-only and idempotent profile provided by annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary action and output details, and the second sentence adds actionable guidance. No filler or redundancy; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior (list, ordering, limit, summary mode) and leverages the existing output schema for return-value details. It omits explicit mention of the filtering parameters, but those are documented in the schema; for a read-only listing tool with this complexity, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the semantic highlights of `limit` (capped) and `summary` (aggregate row per group, preferred for overviews), but does not mention `backup_id`, `datastore`, or `backup_type`. Although the nested schema provides descriptions for most parameters, the context signal reports 0% schema description coverage, so the description must compensate more fully; partial coverage earns a mid-range score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('List snapshots on a datastore') and enumerates the specific data returned (size, file count, protected flag, last verify state), making the tool's purpose unambiguous. It also distinguishes from sibling tools like pbs_list_groups by focusing on snapshots with per-snapshot details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance for choosing between detailed rows and aggregate summary rows ('Set summary=true ... preferred for overviews'), and explains ordering and limit behavior. However, it does not explicitly mention alternative sibling tools or state when not to use this tool, so guidance is solid but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds useful behavioral context by stating that running or failed tasks come with their full UPID, which aids follow-up. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action 'Browse recent PBS tasks', and every clause adds value. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and thorough annotations, the description covers the essential context: the purpose, available filters, and how results relate to follow-up tools. It is complete for a list-style tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions fully document each parameter (limit, running, typefilter, errors_only), so the description does not need to duplicate them. The description does offer a high-level summary of the filters, but adds no new semantics beyond the schema. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Browse recent PBS tasks' with optional filters. It explicitly names the resources (tasks) and verbs (browse), and distinguishes itself from sibling tools by noting that UPID is provided for follow-up via pbs_get_task_status / pbs_get_task_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it's for listing tasks, and the mention of follow-up tools suggests when you might use this (to obtain UPIDs for status/log lookups). However, it does not explicitly state when not to use it or compare directly with alternatives like pbs_list_verify_jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint: true), the description adds valuable behavioral context: GC traverses every chunk, frees unreferenced ones, runs async, returns a UPID immediately, and requires specific environment/permission flags. This exceeds what annotations alone convey and includes no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the primary action, and every word earns its place. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key operational aspects: destructive effect, async execution, UPID return, and required confirm/auth flags. It does not explain the datastore or reason parameters, but an output schema exists and return value behavior is already summarized. Overall, it is sufficiently complete for a destructive background operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only explains the confirm requirement; reason and datastore are left completely unexplained. The agent has no guidance on what values are appropriate or what datastore scoping means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Trigger a garbage-collection run.' It then explains exactly what GC does ('walks every chunk and frees those no longer referenced by any snapshot'), clearly distinguishing it from siblings like pbs_gc_status and pbs_prune.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when to use it (to trigger GC) and provides important operational context: async behavior, immediate UPID return, and the need for PBS_ALLOW_WRITE=true and confirm=true. It does not explicitly name when-not-to-use or alternatives, but the GC-specific wording makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses async execution, return value (UPID), and required conditions (PBS_ALLOW_WRITE=true and confirm=true). These go beyond the annotations, which only indicate non-readonly and non-destructive. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and packs essential details (bitrot purpose, default skip, async, auth) without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the high-level behavior, async nature, default policy, and auth requirement, which is good for an async task trigger. Despite lacking parameter detail, the presence of an output schema and the compact description make it reasonably complete, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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, but it only mentions 'confirm=true' and the default 30-day behavior. It does not explain the other seven parameters such as backup_id, datastore, backup_type, or outdated_after, leaving the agent without guidance for targeted verification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Trigger a verify task' and explains what verify does ('re-reads every chunk and confirms it matches its expected hash, catching bitrot'). This distinguishes it from sibling maintenance tools like pbs_run_gc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context on when to use the tool by mentioning the default skip of recently verified snapshots, implying it's for integrity checks. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds behavioral detail about pagination via start/limit and tail=true returning only the end of the log. It does not describe the return format, but since an output schema exists, that gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant wording. The first sentence states the core function, and the second adds practical pagination/tail guidance, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple log-fetching tool, the description is adequate: annotations cover safety, output schema covers return shape, and pagination/tail behaviors are explained. It could benefit from a brief mention of when to prefer this over pbs_get_task_status, but that is not essential here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is low at 0% for the top-level parameter object, so the description partially compensates by explaining start/limit as pagination and tail=true for the end of the log. The required upid parameter is not described, but it is self-evident from the tool name and schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb+resource pairing: 'Fetch log lines from a PBS task.' This clearly distinguishes the tool from siblings like pbs_get_task_status (status) and pbs_list_tasks (task listing). The added note about checking 'how a verify or GC finished' further clarifies its intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: 'usually all you need to see how a verify or GC finished.' It implies the tail mode is the primary use case. However, it does not explicitly compare with sibling tools or state when not to use it, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context about its aggregating behavior (one-call report spanning multiple subsystems) and its role as a triage tool. It does not describe return format, but an output schema exists and annotations cover safety, so the added context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the resource and the list of health aspects, and the second gives usage direction. No wasted words; every clause contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a complex aggregator with multiple parameters and an output schema. The description clearly states the purpose, the scope of the report, and the appropriate usage context. It is complete enough for an agent to select and invoke it correctly without needing to know every return field in advance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the tool description does not explain the parameters. While the schema provides descriptions for task_hours and stale_hours, the main description only mentions 'datastore' without detailing the configurable look-back windows. It does not compensate for the low coverage, leaving the agent to infer that backup freshness and failed-task windows are adjustable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a health report for a datastore with a specific verb ('health report') and resource ('datastore'), and enumerates the exact aspects covered (storage, node load, GC, snapshots, backup freshness, corrupt groups, tasks). It also distinguishes itself from sibling tools by noting it replaces separate status/gc/tasks/groups calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Start here for any "is PBS okay?" question' and 'it replaces separate status/gc/tasks/groups calls', providing clear when-to-use guidance and pointing to the alternative approach of using individual tools. This is strong usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a write operation requiring PBS_ALLOW_WRITE=true and confirm=true, and explains the consequences on prune/forget. This complements the annotations (readOnly=false, destructive=false, idempotent=true) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose and provide the needed behavioral context without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, behavioral impact, and prerequisites, which is sufficient for a simple flag-setting operation. The output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for each parameter, so the description adds little new parameter-specific meaning beyond reiterating the confirm requirement. Baseline 3 is appropriate as the schema covers the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set or clear the protected flag on one snapshot' with a specific action and resource, distinguishing it from siblings like pbs_forget_snapshot and pbs_prune.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the operational context: protected snapshots are skipped by prune and cannot be forgotten until unprotected, making it clear when to apply protection. It doesn't explicitly name alternatives but gives clear behavioral criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: 'stops at the next safe point' and 'can simply be re-run later' complement the idempotentHint and destructiveHint. It also discloses the required permission (PBS_ALLOW_WRITE=true) and confirm=true, which is valuable operational information not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly worded sentences deliver purpose, use-case, safety behavior, and prerequisites without redundancy. Every clause adds value and the structure is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive stop operation, the description covers why, when, what happens, and what is required. The safety note about re-run and the permission requirement make it self-contained; output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly requires confirm=true, which is critical since the schema has confirm default false and not required. However, it does not explain the 'reason' parameter, and schema description coverage is low (0% per context). The description partially compensates but is not complete for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Abort a running PBS task', clearly identifying the resource and action. The example '(e.g. a GC or verify stuck on a slow NFS datastore)' distinguishes this from sibling tools that list, get status, run, or prune.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete scenario of when to use this tool—when a task is stuck—and explains that an interrupted GC or verify can simply be re-run later, which guides decision-making. It does not explicitly mention alternatives or when not to use it, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, and the description adds useful context about the content (schedule, datastore, re-verify policy) without contradicting annotations. It doesn't detail output format, but the output schema covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, front-loaded with the action and resource, and every word earns its place. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless read-only list tool with an output schema and comprehensive annotations, the description fully covers what the tool does, when to use it, and how it differs from a sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool effectively has no real parameters (only an empty params wrapper), and the description has no need to explain parameters. With zero actual parameters, the baseline is 4, and the description adequately covers the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists configured verify jobs with specific fields (schedule, datastore, re-verify policy) and explicitly differentiates from sibling pbs_list_datastores, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames the tool as answering 'is verification scheduled at all?' and notes that pbs_list_datastores only shows GC/prune schedules, providing clear when-to-use guidance and a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![homelab-pbs-mcp MCP server](https://glama.ai/mcp/servers/ahmetem/homelab-pbs-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ahmetem/homelab-pbs-mcp)

Score Badge

Copy to your README.md:

[![homelab-pbs-mcp MCP server](https://glama.ai/mcp/servers/ahmetem/homelab-pbs-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ahmetem/homelab-pbs-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ahmetem/homelab-pbs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server