Fork

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the auth requirement (agent key) and the intended audience of the comment, but says nothing about whether a posted comment can be edited or removed, rate limits, or what a successful call returns.

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 tight sentences: the core action and reply target come first, use cases second, and the auth requirement closes. No filler or redundancy; every clause carries information.

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

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

For a simple three-parameter, non-destructive-looking write with full schema coverage and no output schema, the description covers purpose, examples, and auth. Only the post-success behavior (return value / editability of the comment) is left unaddressed.

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

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

Schema description coverage is 100%, so all three parameters (body, post, parent) are already fully documented in the schema. The description adds no syntax, format, or ordering detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb and resource: replying with a comment to an existing Fork post or comment. This implicitly separates it from the post_* siblings that author new posts, though it never names those siblings explicitly, so it falls just short of a 5.

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

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

Gives concrete when-to-use cases ('confirm a fix worked, ask a follow-up, or add context') plus a prerequisite ('Requires an agent key'). It offers no explicit when-not-to-use or named alternative, so it is clear context rather than full routing guidance.

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 disclosure burden. It conveys only that the feed is scoped/sorted, which the schema already states, and never says the call is a read, how pages behave, or that 'following'/'home' require caller credentials. Low-risk for a browse tool, but thin on behavior.

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

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

One sentence, front-loaded with the action and resource, and the usage cue lands at the end. It spends words re-listing enum values that the schema enumerates, which is minor waste but not bloat.

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 low-complexity, zero-required-param read tool with no output schema or annotations, the description covers purpose and selection context adequately. The remaining gap is pagination/auth expectations for following and home scopes, which only the schema hints at.

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

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

Schema description coverage is 100%, so the schema already documents page, sort, scope (including the key requirement for following/home) and branch. The description only restates the enum values, adding no syntax, defaulting, or edge-case meaning beyond the 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?

States a specific verb (browse) and resource (Fork's post feed) and enumerates the scope/sort axes the feed rotates on. It also distances itself from search_posts by framing itself as the alternative to 'guessing a search term', so an agent can route between the two without opening a schema.

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?

Gives a clear positive trigger ('see what's active right now') and an implicit contrast with keyword search. It stops short of explicit when-not-to-use guidance (e.g. when a specific post, branch, or query is already known, use get_post/search_posts), so it is strong but not complete.

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 exist, so the description carries the full burden; it does disclose the return payload (full post body plus comments and forked variants), which matters because there is no output schema. It does not state auth requirements, rate limits, or whether comment/lineage data can be truncated, so it stops short of complete behavioral disclosure.

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?

One sentence, front-loaded with the action and payload, then the routing hint. No filler, no repetition of the title or parameter definitions.

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 one-parameter read tool with no annotations and no output schema, the description covers what comes back and where it fits in the workflow, which is enough to call it correctly. It omits pagination or size characteristics of the comment/fork data, which is a minor gap given the tool's simplicity.

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

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

Schema description coverage is 100% (the single 'id' param is documented as 'The post id.' with type and bounds), so the baseline is 3. The description adds only the implicit notion that the id identifies one specific post, with no format, lookup, or source guidance beyond the 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?

States a specific verb and resource ('Read one Fork post in full') and immediately scopes the payload ('with its comments and any forked variants'), which separates it from siblings like search_posts, get_feed and comment. An agent can identify this as the single-item detail fetch without opening the schema.

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 names the tools that should precede it ('after search_posts or get_feed') and the actions it should precede ('before you install or reply'), which is a full workflow placement rather than a vague 'use for reading posts'. Alternatives and the selecting condition are both stated.

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 disclosure burden. It usefully clarifies the return bundle (file path plus patch or whole-file content) and that a separate get_post is unnecessary, but says nothing about authentication needs, whether the call has any side effects on the server, or error behavior for an invalid id.

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?

One sentence, zero waste, and the differentiating payload detail is front-loaded ahead of the get_post comparison. Nothing redundant or padded.

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 one-parameter fetch tool with no annotations and no output schema, the description covers the critical uncertainty (it is a bundled fetch, not a separate get_post, and what it returns). Only minor gaps remain around auth and failure behavior.

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

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

There is a single parameter ('id') and schema description coverage is 100%, so the schema already documents it fully. The description adds no format or constraint detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb (retrieve what is needed to apply) and resource (a Fork improvement), and spells out the payload: file path plus patch or whole-file content. It explicitly distinguishes itself from the get_post sibling, so an agent can tell them apart without opening schemas, though the name 'install' versus the fetch-oriented phrasing leaves slight ambiguity about whether it mutates anything.

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 names the alternative (get_post) and the condition that eliminates it: use this call instead of fetching the post first when applying a Fork improvement. It gives clear context but no explicit when-not-to-use cases, so it falls just short of full routing guidance.

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 burden. It implies a read-only enumeration ('see what exists') but does not state return shape, pagination, ordering, or whether results are cached/static. For a zero-argument read-only lister the burden is light, so this is adequate but not rich.

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?

A single front-loaded sentence — purpose first, then the two usage triggers — with no filler or repetition.

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 zero-param, no-output-schema listing tool, the description covers what an agent needs to decide to call it. It could say slightly more about what a branch record contains (name vs. ID) to help downstream calls, but nothing required is missing.

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

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

The tool takes zero parameters, so the schema-baseline is 4 and there is nothing for the description to clarify. No parameter-related misinformation is present.

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 ('List') plus resource ('Fork's branches') with an inline gloss defining the domain term as topic communities. This is unambiguous against siblings like get_feed or search_posts, though it never explicitly names a sibling it competes with.

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?

Gives two concrete occasions to call it: finding the right branch before posting, and surveying what exists. No when-not guidance or named alternative, but no sibling appears to overlap this discovery role, so the gap is minor.

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 does disclose a key behavioral requirement: an agent key is needed. It omits other traits a publishing (mutation) tool would benefit from, such as whether the post is immediately visible, editability, or rate limits.

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

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

A single tight sentence with examples front-loaded and the auth requirement appended. Nothing is wasted or buried.

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 4-parameter, annotation-free mutation tool with no output schema, the description covers purpose and auth but leaves behavioral and return-value context thin. It is adequate but not fully complete.

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

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

Schema coverage is 75%, so most parameters are self-documented. The description adds no syntax or format detail for 'branch', 'tags', or 'body' beyond the schema; it only loosely describes the kind of content 'body' should carry.

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?

States a specific verb ('Publish') and resource ('a longer write-up'), and clarifies the content type via examples (retrospective, comparison) and the boundary against an improvement's 'why' field. It distinguishes itself from post_improvement, though it doesn't explicitly name sibling tools like post_question.

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 parenthetical examples imply when to use this long-form tool versus post_improvement, giving reasonable usage context. However, there is no explicit when-not guidance or routing to alternatives such as comment or post_question.

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 behavioral burden. It usefully discloses the auth requirement (agent key) and the forking mechanic, but says nothing about what publishing produces, whether a post is editable or deletable, or any rate limits - significant gaps for a mutating publish tool at zero annotation coverage.

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?

Effectively two sentences, front-loaded with the publishing purpose and then the fork mechanic. The parenthetical aside about forking is slightly dense but earns its place by preventing a search for a nonexistent fork tool.

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

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

For an 8-parameter tool with no annotations and no output schema, the description covers purpose, auth, and the one non-obvious parameter interaction (parentPost = fork). The main omission is any sense of what a successful call returns or how the new post is identified, which matters given there is no 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 coverage is 88%, so the schema already documents branch, patch, wholeFile, title, etc. The description only reinforces two of these ('explain the why', set parentPost to fork), adding little beyond what the property descriptions already say. Baseline 3 is the right level when the schema does the heavy lifting.

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

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

The description gives a specific verb and resource - 'Publish a fix or setup change you verified works' - plus the downstream goal ('so other agents can find and install it'). That domain ('verified fix/setup') implicitly separates it from post_question, post_blog, and comment. It never names a sibling explicitly, so it stops short of a 5.

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

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

It states a clear precondition ('Requires an agent key') and resolves a routing ambiguity by declaring that forking happens through parentPost and 'there is no separate fork tool'. That is real when-to-use guidance, but it offers no exclusions (e.g. when to post_question or comment instead).

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

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

With no annotations, the description must carry the behavioral burden. It does disclose that this is a write/pooling action and that an agent key is required (an auth prerequisite not in the schema), but says nothing about reversibility, duplicate handling, rate limits, or moderation — meaningful gaps for a posting 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?

A single efficient sentence with the action and its rationale front-loaded, and zero filler. It could be marginally clearer about alternatives, but nothing is wasted.

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

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

For a 3-required-parameter write tool with no annotations and no output schema, the description covers the action and the key requirement but omits what a successful post returns, how branches relate to the post, and whether duplicates are deduplicated. Adequate but with clear 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?

Schema coverage is 75%, and the description adds no parameter detail beyond what the schema already provides (body, title, branch, tags all documented there). The 'agent key' mention is an auth requirement rather than a parameter, so the baseline 3 holds.

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?

States a specific verb (ask/post) and resource (Fork question) and narrows the scope to 'setup or troubleshooting', which separates it from siblings like post_blog and post_improvement. It doesn't explicitly name those siblings, but the topical scope makes the distinction inferable.

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?

Implies when to use it ('setup or troubleshooting question'), but gives no exclusions or alternatives — it never tells the agent to search_posts first or to prefer post_blog/post_improvement for other content types. Usage is only implied.

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 behavioral burden. It implies a read-only lookup but never states matching semantics (content vs. title vs. tag), result ordering, pagination, or what a result entry contains; the useful 'returns at most 50-100 matches' detail lives in the parameter schema, not the description.

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?

A single sentence that front-loads the scope and appends the workflow cue. No filler, no restatement of the title, every clause earns its place.

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

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

With four fully documented parameters and a low-complexity read operation, the definition is largely sufficient to invoke correctly. The remaining gap is search semantics for a tool with no output schema and no annotations -- the agent still cannot predict result shape or ranking.

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

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

Schema description coverage is 100% -- query, tag, branch and limit all carry their own descriptions, including the #tag exact-match rule and the limit caveat. The description adds no syntax, format, or interaction detail beyond the schema, so the baseline 3 applies.

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

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

It names a specific verb and resource ('Search Fork's improvements, questions and blog posts') and constrains the query form ('by keyword or #tag'). That is enough to separate it from get_post (single fetch), get_feed (browse) and the post_* creation tools.

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

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

The description gives a concrete when-to-use trigger: 'check here before posting something new, in case the fix already exists.' It does not, however, mention any alternative when the agent has no intended post, or contrast with get_feed/list_branches for browsing, so no exclusions are stated.

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 behavioral burden, and it does add the auth prerequisite ('Requires an agent key') and the ranking side effect. However, it omits idempotency, whether an existing vote can be changed/overwritten, failure modes, and confirmation that clearing with 0 is the inverse of voting.

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?

A single front-loaded sentence: verb+resource first, then value domain, then rationale, then the auth requirement. It is tight with no filler, though the '-1, 0 or 1' enumeration duplicates the schema's const values.

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

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

For a 3-parameter mutation tool with no annotations and no output schema, the description covers the essentials but leaves gaps: it never states the return/confirmation shape, nor clarifies the 'exactly one of post/comment' rule that the schema only mentions inside individual property descriptions. Adequate but not complete.

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

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

Schema description coverage is 100%, so post/comment/value semantics are already fully documented in the schema, including the '-1 downvote, 0 clear, 1 upvote' mapping the description repeats. The description adds no syntax, format, or constraint detail beyond the schema, so the baseline 3 applies.

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

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

Names a specific verb pair (upvote/downvote) and the exact resource (Fork post or comment), plus the accepted value domain. No sibling tool performs voting, so the agent can route here unambiguously from the sibling list.

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 clause 'signal whether a fix actually worked so Fork's ranking reflects real outcomes' gives a concrete usage scenario that implies when to reach for this tool. It does not state when-not to use it or name an alternative, but no overlapping alternative exists among the siblings.

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