Retrieve a complete fork record with title, state, participant components, change log, and environment snapshot using app ID and fork ID. Returns an error for unknown fork IDs.
Full record for one fork: title, state (open/merged/deleted), participant components, the complete change log, and its environment snapshot. Returns {error} for an unknown fork_id. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| fork_id | Yes |
Changes observed during successful MCP inspections.
v2.2.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the error behavior for unknown fork_id and confirms read-only status, which is useful context. It does not detail the exact structure of the environment snapshot or change log, but these are secondary details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence listing the record contents, followed by a terse error note and declaration of read-only. Every element adds value, and there is no redundancy or verbosity.
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 read-only tool with no output schema, the description covers the key return elements and error behavior. It lacks parameter clarifications, which are partially mitigated by the explicit fork_id reference, but the absence of app_id explanation and the absence of any example or format details make it slightly incomplete for a tool with this many sibling fork operations.
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 0% coverage; the description provides no explicit explanation of app_id or fork_id beyond a passing reference to fork_id in the error case. It fails to explain the purpose of app_id, leaving the agent to infer it from context. The description should at least clarify that fork_id identifies the fork and app_id scopes it, but it does not.
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 retrieves a full record for one fork, enumerating the specific fields (title, state, participants, change log, environment snapshot). It also distinguishes it from fork_list and fork_log by the scope (one fork vs list/log), and mentions the error case for unknown IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving detailed information about a single fork, which is clear from the 'one fork' phrasing and the fields listed. It does not explicitly name alternatives or provide when-not-to-use guidance, but the read-only nature and single-fork scope make the intended usage reasonably inference-able.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.