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

With no annotations, the description carries full burden. It discloses that invitees must accept GitHub invitation before pushing, requires gh CLI authenticated with admin, and returns the clone URL. These are critical behavioral traits not inferable from schema.

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

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

Five sentences, front-loaded with purpose, then usage, parameters, and caveats. Every sentence adds distinct value with no filler or redundancy.

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

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

Covers action, when to use, parameter syntax, prerequisites, return value, and invitation acceptance flow. Complete for a simple tool with an output schema.

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

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

Schema has no descriptions (0% coverage). The description fully explains github_username with format and examples, and permission with allowed values and default, adding all necessary semantics beyond raw schema.

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

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

Specific verb 'Invite' and resource 'collaborators on the shared repo' clearly defined. Distinguishes from sibling provision by explicitly stating provision does this only during first-time setup, while this tool is for existing repos.

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

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

Explicitly states when to use: 'Use this when the repo already exists and you just want to grant partners access.' Names provision() as an alternative and clarifies the difference. Also notes prerequisite authentication and invitation acceptance.

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

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

With no annotations, the description carries the full burden, and it delivers. It explains the two detection levels, clarifies that claim_overlap only exists where intent was declared, and warns that an unknown branch yields an explicit 'status':'unknown' object rather than an empty list, preventing misinterpretation of all-clear results.

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

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

The description is well-structured and front-loaded: it starts with the main purpose, then uses bullet-like lines to describe the two levels, followed by the scoping rule. Each sentence adds meaningful information without redundancy or fluff.

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

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

For a single-parameter tool with no annotations, this description is thorough. It covers the tool's behavior, edge cases, and scoping options, while the presence of an output schema means return-value details are already represented elsewhere. It fully enables 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.

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

The input schema provides only a parameter name and default, with 0% description coverage. The description fully compensates by explaining the semantics of against_branch: it checks one specific branch, while the default checks all peer branches in active claims. It also mentions the edge case of naming a branch with no active claim.

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

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

The description starts with a specific verb and resource: 'Detect conflicts between your branch and your partners' branches.' It clearly distinguishes the tool's intent from siblings by naming two concrete output levels, claim_overlap and merge_conflict, which are unique to conflict checking.

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

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

The description provides clear context on when to use the tool and how to vary its scope: 'default checks every branch named in a peer's active claim' and 'against_branch lets you check one specific branch.' It does not explicitly mention alternatives or when-not-to-use cases, 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.

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

With no annotations provided, the description fully shoulders the transparency burden. It discloses the refusal behavior with status='blocked', the overlap evaluation against freshly fetched state, the force flag semantics, and that it returns exact overlap details. This goes well beyond the minimum.

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

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

The description is tightly organized: a one-line purpose, a bullet-style parameter list, and a focused explanation of collision handling. Every sentence contributes value, and the formatting enhances readability without redundancy.

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

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

The description thoroughly covers the claim's conflict behavior, force semantics, and state freshness, which are the tool's complex aspects. Missing pieces include the 'task' parameter definition and any explicit usage guidance, though the output schema may handle return value details. Overall, it is quite complete but has notable gaps.

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

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

The description explains the meaning of touches, requires, branch, and force in plain language, which is essential given the schema has 0% description coverage. However, it completely omits the required 'task' parameter, leaving its purpose ambiguous and reducing the overall semantic coverage.

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

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

The description opens with a clear verb+resource statement ('Stake a claim on a unit of work') and elaborates with parameter meanings and collision behavior. This distinguishes it from sibling tools like check_conflicts and release by describing a claim creation action with exclusive overlap detection.

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

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

The description clearly implies this tool is for claiming work and explains the force option, but it does not explicitly state when to use it versus alternatives such as check_conflicts or release. There is no mention of exclusions or alternative tool recommendations, so usage guidance is left to inference.

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

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

With no annotations, the description carries the full burden and does this well. It discloses side effects (claim marked done, PR opened), ordering ('after the PR is opened'), external dependency (gh CLI), a precondition (branch must be pushed), and an idempotent fallback (returns existing PR URL instead of erroring).

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

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

The description is front-loaded with the core purpose, then uses compact labeled lines for parameters, followed by a concise block of behavioral notes. Every sentence adds useful information, and the structure makes it easy to scan.

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

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

The description covers prerequisites, side effects, fallback behavior, and the gh CLI requirement. Since an output schema exists, the description does not need to explain return values, and it even mentions the existing-PR return behavior. It is complete for an agent selecting and invoking the tool.

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

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

Schema description coverage is 0%, but the description compensates fully. It maps note to PR body with fallback to claim note, title to PR title with fallback to claim task, and draft to opening the PR as draft. This gives the agent meaningful guidance beyond the raw property names.

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

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

The description opens with a clear verb+resource pair: 'mark your claim done AND open a GitHub pull request from your claimed branch into the default branch.' This unambiguously states what the tool does and distinguishes it from siblings like claim, update_status, or release by combining completion of the claim with PR creation.

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

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

It provides explicit context for when to use the tool: after the branch is pushed and when ready to move work into review. It also mentions the gh CLI requirement and the behavior if a PR already exists. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a perfect score.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the source (git history of claims.json), ordering (newest first), and limiting behavior (`limit` caps events), effectively conveying a read-only operation without side effects. It does not mention potential errors or auth requirements, but the described behavior is sufficient for this simple read tool.

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

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

The description is two sentences, front-loaded with the main purpose and followed by a practical use case. Every sentence adds value, and there is no redundant or filler content.

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

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

With an output schema present and only one optional parameter, the description covers the essential aspects: purpose, source, ordering, limiting, and a suggested scenario. It is complete enough for an agent to select and invoke this tool correctly without additional context.

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

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

The schema has only a 'limit' parameter with no description (0% coverage). The description explicitly explains that `limit` caps how many events are returned, giving the parameter clear meaning and compensating fully for the missing schema description.

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

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

The description clearly states it provides a coordination timeline from git history, listing who claimed, finished, or released what and when. This is specific and distinct from sibling tools that perform actions like claim, finish, release, etc., so it differentiates itself well.

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

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

It gives a concrete use case: 'what has my partner been doing?' without needing them online, implying it is the appropriate tool for checking activity asynchronously. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough.

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

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

With no annotations, the description fully carries the transparency burden. It discloses the exact order of operations, that steps are skipped if already done, that it creates local files and a remote repo, pushes, seeds, and invites partners. It also notes the auth requirement, providing a comprehensive behavioral picture.

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

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

The description is well-structured, starting with the core purpose, then a numbered step list, then parameter notes. It is long but each sentence provides value—no fluff, clear headings, and appropriate front-loading.

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

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

Given the tool's complexity, the description fully covers prerequisites, actions, idempotency, and return value ('Returns a summary... plus the clone URL'). The presence of an output schema means return format details need not be repeated, and the description still mentions the key output.

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

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

Schema description coverage is 0%, so the description compensates thoroughly. It explains each parameter: repo (owner/name, bare name, or empty), partner_github (usernames, separators, override), private (default private), and description (optional). This adds critical meaning beyond the schema's type/default fields.

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

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

The description clearly states the tool's function: 'Create the shared GitHub repository if it doesn't exist yet, then leave both collaborators ready to use the claim protocol.' It uses a specific verb (create) and resource (GitHub repository), and the detailed numbered steps distinguish it from sibling tools like survey/claim.

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

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

Explicit guidance is given: 'Run this ONCE, by one person, before anyone calls survey()/claim().' It also mentions idempotency and prerequisites (gh CLI, auth), making it clear when to use versus relying on sibling tools.

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

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

The description discloses key behavioral traits: it abandons without marking done, frees files for a partner, and pushes immediately. It also warns about the consequence of not using it (blocked files). Since there are no annotations, the description carries the full burden and does so well, though it omits details like reversibility or permission requirements.

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

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

The description is only two sentences, front-loaded with the core action, and every sentence provides value. It is concise without being under-specified, covering purpose, usage context, and a critical warning in a compact form.

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

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

The description is complete for the tool's main purpose: it clearly explains what the tool does, when to use it, and the immediate effect. It lacks explanation of the 'note' parameter, but given the simple optional parameter and presence of an output schema, the overall context is well-covered.

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

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

The schema has one parameter 'note' with no description, and the tool description does not mention this parameter at all. With 0% schema description coverage, the description was expected to explain the parameter's meaning, but it completely ignores it, leaving users to guess what 'note' does.

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

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

The description states exactly what the tool does: 'Abandon your current claim WITHOUT marking it done, freeing the files you were holding so a partner can take them over.' This uses specific verbs and resources, and clearly distinguishes from siblings like 'finish' (which likely marks done) and 'claim' (which acquires a claim).

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

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

The description explicitly says when to use it: 'Use this when you're dropping the task or stepping away.' It also names alternatives: 'the only other exits are 'done' or manual git surgery,' providing clear decision-making context versus sibling tools like 'finish.'

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

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

With no annotations, the description discloses the stale flag semantics, age_hours, and the AGENTSYNC_STALE_HOURS default, and clarifies it reports on *other* agents only. It does not explicitly state read-only behavior, but 'Pull' implies non-mutating.

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

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

Two paragraphs, every sentence adds value; front-loaded with the core function, then flags and usage.

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

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

For a no-input read tool with an output schema, the description covers the important output semantics (stale flag, default threshold, scope) and provides usage guidance; nothing obvious missing.

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

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

The input schema has zero parameters, so the description needn't explain any. Baseline 4 applies since there's nothing to document.

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

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

The description clearly states the tool 'Pull[s] the latest coordination state' and enumerates the specific fields reported (task, files touched, dependencies, branch, status, timestamp), distinguishing it from sibling tools like claim, release, or check_conflicts.

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

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

Explicitly says 'Call this before planning and again after finishing work,' giving clear timing. It also notes it works for any number of collaborators, but does not explicitly name alternatives or when-not to use.

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

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

Despite lacking annotations, the description discloses key behavioral traits: pushes immediately, auto-annotates with changed_files on 'done', and notes are for a partner. It could add details on reversibility or error handling, but the side-effect disclosure is substantive.

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

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

Two sentences, front-loaded with the main action, then behavioral details, then alternative tools. No fluff; every clause adds value.

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

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

Given the tool's simplicity (2 params, no annotations), the description covers purpose, usage, parameters, behavior, and alternatives. Output schema exists so return values need not be described. 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.

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

Schema description coverage is 0%, so the description must explain parameters. It does so by defining 'status' (with an example transition) and 'note' (for the partner). It doesn't enumerate all allowed statuses, but the example provides sufficient guidance.

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

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

Clearly states the tool updates your own claim's status, with a concrete example and optional note attachment. It distinguishes itself from sibling tools by naming release() and finish() as alternatives for different workflows.

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

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

Explicitly describes when to use this tool versus alternatives: 'To drop a claim without finishing it, use release(); to finish AND open a PR, use finish().' Also implies the constraint that you can only update your own claim.

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