agentpack
Server Quality Checklist
Latest release: v1.6.1
- Disambiguation5/5
Most tools have clear distinct purposes. The only potential confusion is between load_context and resume, but descriptions differentiate them (session start vs. ad-hoc re-read). Overall, agents can easily distinguish tools.
Naming Consistency5/5All tools follow a consistent verb_noun snake_case pattern (e.g., attach_evidence, task_start, bundle_export). No mixing of conventions.
Tool Count4/526 tools is on the higher side but appropriate for the comprehensive workflow management domain. Some tools could be merged (e.g., load_context and resume) but each has a specific use case.
Completeness4/5Covers task lifecycle, evidence, checkpoints, source caching, bundles, and release preflight thoroughly. Minor gaps like evidence retrieval or task deletion tools are absent but not critical.
Average 4.5/5 across 26 of 26 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 128 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'identical repeated calls are no-ops,' which directly contradicts the idempotentHint=false annotation. It also fails to address the destructiveHint=true annotation, leaving potentially destructive behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, lifecycle effects, and sequencing/idempotency. No filler or redundancy, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose, state transitions, and call sequence, but given the no-output-schema and destructiveHint=true annotations, it omits return value, potential destructive side effects, and error/failure handling. This is a significant gap for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all parameters, but description adds meaningful context: it distinguishes 'passed, failed, or accepted' as final verdicts versus 'pending or unknown' that reset to active, and links evidence to attach_evidence. This enhances understanding beyond the terse schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Update') and resource ('current Task Passport verification state'), clearly distinguishing it from general task tools like task_update. It also defines the scope with lifecycle effects, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context by instructing to call after attach_evidence and explaining lifecycle transitions for final vs non-final statuses. However, it does not mention when not to use the tool or name alternative tools.
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?
The description discloses that it writes a file under .agentpack/evidence/ and adds a ledger event, which is useful context beyond the annotations' readOnlyHint=false. However, it does not mention overwrite behavior, whether directories are created, or failure modes. Annotations already cover core traits, so the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences pack purpose, usage guidance, and parameter interplay without unnecessary detail. It is front-loaded with the primary function and returns an id. Slightly long but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, when to use it, how to provide evidence (inline or file), and what the id is used for. With no output schema, it doesn't over-explain return values. It could mention that the ledger event is also a record, but overall it is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds key semantics: 'content is ignored when path is set' and 'kind json stores the file with a .json extension' and that command/exitCode are stored as metadata. This goes beyond the schema descriptions and clarifies parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Store') and resource ('verification output as a file under .agentpack/evidence/ plus a ledger event'), and it explains the returned evidence id's purpose for reference from other tools. This clearly distinguishes attach_evidence from siblings like record_decision and task_update_verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call for meaningful verification worth preserving and provides aggregation guidance ('for small tasks prefer one aggregated evidence item over many per-command items'). It also explains the two input modes (inline content vs. path). It does not name alternative tools when not to use, but the guidance is clear enough.
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 readOnlyHint=true, and the description reinforces with 'without writing anything' and 'explicit read-only guarantee.' It adds behavioral detail about the return: 'create, idempotent, or conflict actions,' which is not in annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The first sentence states the core function and guarantee; the second gives a direct call-to-action tying to bundle_import.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a preview tool with no output schema, the description adequately describes return categories (create/idempotent/conflict) and the read-only nature. It also clarifies the relationship to bundle_import. Minor gaps like error handling are acceptable for this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (json, path, asNew) is already well-documented. The description adds no additional parameter semantics beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Plan' and identifies the resource 'task bundle import against this pack' with the scope 'without writing anything.' It clearly differentiates from bundle_import by stating it previews what the write would do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call to preview exactly what bundle_import with write: true would do' provides explicit guidance on when to use this tool (as a pre-flight to bundle_import). It implies the alternative is bundle_import for actual execution, though it doesn't explicitly name 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?
The description reinforces the readOnlyHint annotation with the explicit statement 'Read-only — never writes pack state,' adding a concrete behavioral guarantee beyond the annotation. It also signals safety for untrusted files, which is valuable context. The openWorldHint is not contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each packing distinct value: the first describes what the tool does and its output categories, the second provides safety and usage timing. No redundant words; information is front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description enumerates the key output categories (schema/digest status, origin, records, warnings) and gives safety guarantees and usage timing. For a read-only inspection tool with full annotations and schema, this is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (path and json) already described clearly in the input schema. The description does not add additional parameter-level meaning—it only mentions 'task bundle file' without elaborating on the path or json flag. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates and summarizes task bundle files, listing specific output aspects (schema and digest status, origin, included records, warnings). The verb 'validate and summarize' plus the resource 'task bundle file' precisely defines the action, and the mention of 'untrusted' and 'before planning or applying an import' distinguishes it from sibling tools like bundle_import_plan and bundle_import.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Call before planning or applying an import of a bundle you did not produce.' This gives clear contextual guidance. However, it does not explicitly name alternatives or when-not-to-use conditions, so it falls short of a full 5.
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 it read-only, and the description reinforces this with 'Read-only.' It adds behavioral context beyond annotations by describing the default comparison (previous vs latest) and the exact data presented (summaries, status lines, git refs), which is valuable for callers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences. Each sentence contributes either functionality, defaults, or usage guidance. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with full parameter schema coverage and no output schema, the description effectively conveys purpose, usage scenario, default behavior, and output content. It is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in the schema. The description's mention of defaults aligns with the schema but does not add new semantic meaning beyond what schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compare two checkpoints' with specific output details ('summaries, status lines, and git refs side by side'). This distinct verb+resource combination differentiates it from sibling tools like checkpoint or bundle_inspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Call to see what changed between sessions' and explains default behavior. However, it does not explicitly mention alternatives or when not to use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only behavior is already declared via annotations, but the description adds useful context beyond that: the output includes all Task Passports, and the current task is marked with an asterisk. This discloses behavior not present in the annotations and helps the agent anticipate the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function, followed by usage guidance and the read-only note. Every sentence contributes value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter and no output schema, the description is complete. It names the fields returned, explains how to identify the current task, and states when to use it. No important information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single optional 'json' parameter with its own description. The tool description does not add additional parameter semantics beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all Task Passports with id, status, title, and branch.' It uses a specific verb ('List') and resource ('Task Passports'), and includes the exact output fields. It also distinguishes itself from siblings by noting the current task is marked with an asterisk and by referencing task_switch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Call to find a task id for task_switch or to review open work.' This gives a clear scenario for when to use the tool. It does not explicitly mention when not to use it or compare with alternative list tools like task_status, but the guidance is strong enough for a list tool.
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 mark this as destructive, and the description adds detailed state-transition behavior for parked targets with different verification states, plus the side effect of updating the .agentpack/ pointer. This goes beyond the annotation flags 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each focused: purpose, behavioral nuance, and precondition/side effect. Front-loaded with the core action; no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description covers purpose, state transitions, preconditions, and side effects. All necessary operational context is present, handling the tool's complexity well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'id' parameter described as 'Task Passport id to switch to (see task_list).' The description adds no additional parameter semantics beyond confirming the id is used, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Make another open Task Passport current by id'), specifying the resource and operation. It distinguishes from siblings like task_start and task_park by focusing on changing the current-task pointer, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states a prerequisite ('Park or finalize a different active, blocked, or verifying current task first') and an exclusion ('closed tasks cannot be switched to'), giving concrete guidance on when it can be invoked. It does not explicitly name alternative tools, but the context is sufficient.
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 destructiveHint=true, and the description adds useful context: the checkpoint is durable, captures git state, updates pack-level status/next actions, and seeds the next session's load_context. It does not contradict annotations and provides behavioral detail beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the action and resource, then provides usage timing. Every phrase adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and three well-documented parameters, the description covers purpose, side effects, and usage timing. It could mention what the return value is or explicitly state that previous checkpoints are overwritten, but the schema hints at 'replacing' and the overall context is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the schema already explains them thoroughly. The description reinforces that status and nextActions get updated, but does not add meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Save') and resource ('.agentpack/checkpoints'), and details what is captured (summary and git state) and updated (pack-level status and next actions). This distinguishes it from sibling tools like load_context by explicitly noting it seeds the next session's load_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('after meaningful progress, before ending a session, or before risky changes') and when not to use it ('not after every small step'). This provides strong usage guidance, even though it does not name alternative 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?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds useful behavioral context beyond annotations, including the resume contents and that it behaves identically to load_context but with adjustable query/budget. The read-only statement reinforces the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and contents, then gives usage guidance and a read-only note. Every sentence serves a purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, contents, usage timing, and safety for a moderate-complexity tool. While no output schema exists, the description adequately implies the markdown resume output. It could have elaborated on exact return formatting or edge cases, 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description references 'query or budget' but does not add meaningful parameter detail beyond what the schema already provides for query, budget, and preset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as generating a token-budgeted markdown resume with specific contents (Task Passport state, git state, query-relevant records, gate warnings). It also explicitly distinguishes resume from load_context by positioning it as the ad-hoc re-read variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: prefer load_context at task start, use resume for mid-session re-reads with different query or budget. This directly addresses when to use the tool vs. alternatives and provides exclusion criteria.
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 the description reinforces this with 'Read-only.' More importantly, it adds context about the audit's scope (specific risk categories), going beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the audit's purpose and contents, the second gives usage guidance. It is front-loaded, concise, and every word serves a purpose with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional param, read-only) and the description covers purpose, scope, and usage well. However, it doesn't mention the return/output format, and since there is no output schema, this is a minor gap that prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'json' is fully described in the schema ('Return structured JSON instead of formatted text.'). The description adds no additional parameter information, so the baseline 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Audit') and resource ('current Task Passport') followed by a precise list of what the audit checks (stale/missing sources, branch/head drift, etc.). This clearly distinguishes it from sibling tools like task_status or source_status by focusing on continuity risks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call ('before finalizing, after a long gap, or when drift is suspected') and when to skip ('when a recent audit already answered it'). This provides concrete usage context and an exclusion, though it doesn't name alternative tools.
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 reveals that the tool writes only a new bundle file and leaves pack state unchanged, which is critical side-effect information given all annotation hints are false. It also mentions the output is 'redacted,' adding behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences. The first establishes purpose and scope; the second clarifies the side-effect boundary. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 params, full schema coverage, and no output schema, the description adequately covers purpose, output, and side effects. It's sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions (100% coverage). The tool description itself doesn't add parameter details beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports one Task Passport with decisions, dead ends, source conclusions, and optionally evidence to a redacted agentpack.task-bundle JSON file. It distinguishes from siblings like bundle_inspect (inspect) and bundle_import (import) by specifying the export action and sharing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'for sharing tasks across repos, machines, or agents.' It doesn't explicitly name alternatives or exclusions, but the context is sufficient to infer when to use it.
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 goes far beyond the annotations by detailing that the default is a read-only plan, a write import runs under pack lock, creates a parked task, resets verification to unknown, retains bundle and manifest, and never changes the current-task pointer. This is rich behavioral context not captured 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four well-structured sentences, front-loaded with the purpose, followed by default behavior, write side effects, and a safety note. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately explains the return (read-only plan) and fully discloses the side-effect profile of write mode. It also includes safety guidance, making it complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all four parameters with clear descriptions, including the write param. The description reinforces the write behavior but does not add new parameter-level meaning beyond what the schema provides, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Import a task bundle into this pack' with a specific verb and resource, and distinguishes itself from siblings by explaining the default read-only plan mode and the write behavior, making it distinct from bundle_inspect and bundle_import_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Inspect or plan untrusted bundles first', pointing to alternatives for inspection/planning. It also clarifies when to use write=true for actual import, providing clear context on usage, though it does not name sibling tools directly.
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 declare readOnlyHint=true, and the description adds 'Read-only' while also revealing token-budgeting behavior and the presence of gate warnings. This goes beyond the annotation by explaining what the resume includes and how the tool handles queries, though the exact output format is not specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet information-dense, using three sentences to convey the core function, usage frequency, and safety note. Each clause contributes value, and key facts are front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With read-only annotations and a fully described schema, the description explains what the resume contains (status, git, decisions, dead ends, conclusions) and when to call/re-call. Although there is no output schema, the content outline is sufficient for an agent to understand the tool's behavior and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed param descriptions for query, budget, and preset. The description only references 'query or budget' in usage guidance without adding new semantic detail, so the baseline score of 3 applies as the schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a token-budgeted markdown resume of Agentpack state, enumerating specific content like Task Passport status, git state, decisions, and gate warnings. This distinguishes it from sibling tools by its start-of-session context-loading purpose and explicit resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call once at the start of a session or task, before reading code; re-call only for a different query or budget.' This establishes when to use the tool, when not to re-call, and the rationale for doing so, though no alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden. It discloses the write side effect ('Writes one event under .agentpack/') and redaction behavior ('secret-like values are redacted'), which goes beyond the minimal annotation information. However, it doesn't mention idempotency explicitly, though annotations already say idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter logging tool with no output schema, the description covers purpose, usage, side effect location, and security behavior. It's fully sufficient for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds the general context of redaction but doesn't add specific parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Record an approach that failed.' It also distinguishes from siblings by noting it's for durable abandonments, not debugging iterations, which separates it from record_decision and other logging tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 'Call when an attempted direction is abandoned for a durable reason' and when-not-to-use: 'not for ordinary debugging iterations.' This provides clear context without needing to name alternatives.
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 the description reinforces and expands this by asserting 'never pushes, tags, publishes, or creates GitHub Releases,' which adds specific side-effect guarantees beyond the generic annotation. It also clarifies the local scope of the report, providing useful 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose ('Report local release readiness'), followed by content details, a read-only caveat, and usage context. Every sentence earns its place with no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the categories of information reported (release metadata, Trusted Publisher wiring, manual release-prep commands), covers the read-only safety profile, and specifies when to call it. For a parameterless report tool, this provides complete context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is inherently 100%. The description compensates by outlining the content of the report (metadata, Trusted Publisher wiring, commands), giving the agent meaningful expectations for what the tool returns despite having no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Report'), the subject ('local release readiness'), and specifies the exact content (release metadata, Trusted Publisher wiring, manual release-prep commands). It distinguishes this tool from routine work by noting it's for release preparation, making it distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Call when preparing a release, not during routine work,' providing both a clear when and when-not. However, it does not name any alternative sibling tools, so it stops short of the full 5 which requires explicit alternatives.
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 the description reinforces with 'Read-only'. It adds useful behavioral detail beyond annotations: one line per event, timestamp/type, and chronological ordering. This helps the agent understand output expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences effectively cover purpose, usage, output format, and read-only nature. Every phrase earns its place with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter, the description is fully sufficient. It covers event scope, output shape, usage timing, and exclusion from the routine loop, requiring no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'limit' is fully described in the schema (default 30). The description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prints a chronological timeline of ledger events, listing specific event types and output format. It also differentiates from siblings like resume by noting 'when a resume is not enough'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('audit how the task history unfolded') and when not ('not part of the routine load_context/checkpoint loop'). References resume as the alternative that falls short, providing clear usage context.
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 meaningful behavioral context beyond the readOnlyHint annotation by listing what the generated handoff includes and explaining that its purpose is to let another party continue the work. It also confirms 'Read-only,' matching the annotation. It doesn't discuss side effects or failure modes, but for a zero-parameter read-only tool the disclosure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the core action and output structure. The first sentence packs the purpose and content list; the second adds a crisp usage instruction. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema, the presence of readOnlyHint, and the absence of an output schema, the description is complete: it names the output sections and the exact timing for use. An agent can confidently select and invoke this tool without needing further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the schema fully covers the input side with 100% coverage. The description appropriately focuses on behavior and output content rather than parameter details, meeting the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generate a compact handoff for the current Task Passport' — a specific verb and resource — and enumerates the exact sections the handoff contains (objective, constraints, write scope, next actions, verification, drift, audit summary). This clearly differentiates it from sibling tools by focusing on context transfer to another agent, not just status reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage trigger: 'Call before switching contexts.' It also specifies the intended audience ('another chat, client, worktree, or agent'). However, it does not explicitly mention when not to use it or contrast with alternatives like checkpoint or task_park, so it's not a full when/when-not guide.
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?
All four annotation hints are false, so the description carries the burden of behavioral disclosure. It reveals persistence behavior ('persisting under .agentpack/'), a conditional refusal to overwrite active tasks, and the writeScope gate requirement. These are genuine behavioral traits beyond what the schema or annotations provide. Lacks mention of return values or side effects on failure, but is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, followed by usage conditions and a critical parameter hint. No filler or repetition of schema details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and uninformative annotations, the description covers the essential behavioral contract: creation, persistence, current-task semantics, refusal conditions, and gate interaction. It does not explain return values or error handling, but for a create tool with this richness, it is largely complete. Minor gap: no mention of what happens to an existing current task besides refusal, but that is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by singling out writeScope: 'Declare writeScope so the task gate can protect the task's boundaries' – explaining why this parameter matters and how it interacts with the system. This extra context goes beyond the schema's basic description of the field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new Task Passport and make it current, persisting it under .agentpack/' – a specific verb (create), resource (Task Passport), and outcome (make current). This clearly differentiates it from sibling tools like task_park or task_finalize, which manage existing tasks rather than creating them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'Call when starting a coherent phase of work and no task is active'. It also provides exclusions and alternatives: 'it refuses to replace an active, blocked, or verifying current task — park or finalize that task first'. This gives clear when/when-not guidance and names alternative tools.
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?
Annotated readOnlyHint=false already indicates a write, but the description adds location ('writes one event under .agentpack/') and a security behavior ('secret-like values are redacted'), which are not present in structured annotations. This provides valuable behavioral context without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the first states the purpose and persistence, the second gives usage boundaries, and the third discloses location and redaction behavior. Every sentence earns its place and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write tool with no output schema, the description covers purpose, when to use (and not use), the write location, and redaction behavior. This is complete enough for an agent to select and invoke the tool correctly, especially given the high schema coverage and distinction from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes all three parameters (text, files, evidence) with 100% coverage, so the baseline is 3. The description does not add parameter-specific detail (e.g., format of files or evidence), but the schema is sufficient; the redaction note is general rather than parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'Append' and names the resource 'technical or product decision to the Agentpack ledger', clearly stating the persistence goal so future sessions inherit it. This distinguishes it from sibling tools like record_dead_end or record_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'decisions that matter beyond this session (architecture, contracts, tradeoffs)' and when not to: 'not for routine preferences or per-edit narration'. This provides clear usage criteria and exclusions without needing to reference 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 declare readOnlyHint=true, and the description adds 'Read-only,' reinforcing that. Beyond annotations, it discloses the mechanism ('by re-hashing the files') and the purpose of filters ('for stale source-cache triage'). This adds meaningful context about how the tool behaves without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a one-word safety indicator. The main action is front-loaded, usage guidance follows, and every phrase earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with three optional boolean parameters and no output schema, the description covers purpose, usage context, and parameter rationale. It is self-contained and gives the agent enough to decide when to call and what to expect, especially with annotations supporting the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description enriches parameter meaning by connecting 'changed/missing filters' to the tool's purpose ('for stale source-cache triage'), explaining why you'd use those flags. It does not repeat schema descriptions but adds operational context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check whether recorded source conclusions are unchanged, changed, or missing by re-hashing the files.' It clearly distinguishes itself from siblings like load_context and task_audit by focusing on stale-source checks via re-hashing. The purpose is unambiguous and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Call when you need a full stale-source check beyond what load_context already showed; do not repeat it when a recent load_context, task_audit, or status check answered the question.' This states both when to use and when not to use, naming alternative tools and providing a clear decision rule.
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?
Beyond the destructiveHint annotation, the description adds behavioral context: the requirement that verification already be passed/failed/accepted or set via status, the force requirement for accepted finalization, and the return of non-blocking hygiene advisories. This adds value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, each delivering unique information: purpose, precondition, alternative tool, and return value. No redundancy or fluff; the description is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description properly discloses the return value (hygiene advisories) and covers preconditions, alternatives, and force behavior. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3, but the description adds meaning to the status and force parameters. It explains that passing status explicitly can satisfy the verification precondition and that force is needed when next actions remain for accepted finalization, illuminating parameter interplay.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Close the current Task Passport', which is a specific verb and resource. It explicitly distinguishes itself from task_park for deferred work, making the purpose clear and differentiating from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: 'Use task_park for deferred work instead of closing it' and clarifies the force condition for accepted finalization with remaining next actions. It also states the verification precondition, so the agent knows when invocation is valid.
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 indicate destructiveHint=true, but the description adds meaningful context: parking preserves verification state and is resumable, and it does not finalize. This goes beyond the annotation to clarify the exact behavioral semantics, though it doesn't mention any authorization needs or additional side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: first states the action and benefit, second explains the intended use case, third provides a critical exclusion. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description fully covers its purpose, usage context, exclusions, and related tools (task_switch, task_finalize). Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, there is no parameter information to add. The baseline for zero-parameter tools is 4, and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark the current Task Passport parked') and its purpose ('so unrelated work can start without finalizing it'). It distinguishes this tool from siblings by explicitly contrasting with task_finalize and mentioning task_switch for resumption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('intentionally deferred work'), explains what it preserves, and gives a clear exclusion ('Do not park to skip verification of finished work') with the correct alternative tool named (task_finalize). This is exemplary usage 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?
The description discloses a specific behavioral trait beyond the readOnlyHint annotation: it does not scan the source cache, which affects performance and output. It also mentions 'gate warnings' as part of the output. However, since the tool is read-only and no side effects exist, the added context is sufficient but not overly rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first tells what it does and its key behavioral constraint, the second gives usage guidance and a read-only note. Every word earns its place, and it is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, no output schema, and readOnlyHint annotation, the description provides a complete picture: what it returns, when to use it, and the alternative. For a simple read-only snapshot tool, no further information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The baseline for 0 params is 4. The description focuses on the output and usage, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Print') and resource ('current Task Passport'), and specifies the exact contents (status, objective, next actions, verification) plus gate warnings. It also distinguishes the tool from siblings by noting it does not scan the source cache and explicitly points to task_audit for a different use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Call for a fast lifecycle check; use task_audit for the full continuity audit.' This clearly says when to use this tool and which alternative to choose for a different need. The 'without scanning the source cache' further signals it is a lightweight operation.
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?
Goes well beyond the annotations by disclosing key behaviors: list fields append and deduplicate, omitted fields are preserved, empty/no-op updates fail, and clearNextActions switches append to replace. These semantic details are crucial for safe use and are not present in the structured 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then packs essential behavioral details into two sentences. There is no filler or repetition of schema information; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema), the description covers all critical usage aspects: the general patch behavior, list update semantics, preservation rule, failure condition, and the special replace flag. It is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though the schema covers each parameter, the description adds important cross-parameter semantics: append-and-deduplicate for all list fields, preservation of omitted fields, the global failure on no-op updates, and the special replace behavior for nextActions. This meaningfully enriches the parameters beyond their individual schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Patch') and resource ('current Task Passport'), and explicitly distinguishes the tool by noting it does not change lifecycle status. It also enumerates the affected fields, making its purpose unmistakable even among many sibling tools that change status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is for updating passport fields without status changes, and gives a concrete use case for clearNextActions ('to clear a stale plan before finalizing'). However, it does not explicitly name alternatives or state when not to use the tool, so it stops short of full when/when-not guidance.
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 the write behavior ('Writes under .agentpack/'), the caching mechanism (stores content hash with summary, reusable until file changes), and the durable conclusion nature. These details add meaningful context beyond the annotations, especially given destructiveHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a clear purpose statement, followed by usage guidance and a storage side note. Every sentence carries useful information without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set, absence of output schema, and provided annotations, the description is complete: it states what it does, when to use it, where it writes, and the cache invalidation behavior. There are no significant gaps in understanding how to invoke and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining that 'summary' is always expected with a fallback to a generic 'Reviewed source.' It also clarifies how the summary is used with the content hash, providing value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Record') and resource ('source file in the Source Cache'), explaining the caching mechanism and reuse. It distinguishes itself from sibling tools like record_decision and record_dead_end by focusing on source files and content hashes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given on when to use ('Call after inspecting an important file when the conclusion is reusable') and when not to ('do not record every file read'), plus when to re-record ('only when the conclusion itself changed'). This provides clear context for selecting this tool over alternatives.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ihorponom/agentpack'
If you have feedback or need assistance with the MCP directory API, please join our Discord server