create_version_share_linkGenerate a durable public or code-protected link for an exact saved version. Using the same idempotency key returns the original link.
Create or recover a durable public or code-protected link for one exact saved version. Reusing the idempotency key returns the original result.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| access | Yes | ||
| project_id | Yes | ||
| version_id | Yes | ||
| idempotency_key | Yes |
Changes observed during successful MCP inspections.
v0.3.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true, and the description adds meaningful detail that reusing the idempotency key returns the original result, implying a 'create or recover' behavior. This goes beyond the bare annotation and aligns with the idempotency hint, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with no filler. The core purpose and idempotency behavior are stated efficiently, earning every word.
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 5 parameters and no output schema, the description covers the core behavior and idempotency but omits details about the optional 'page' parameter, return format, and error cases. It is sufficient for basic tool selection but not for fully anticipating edge cases.
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 compensate. It adds semantics for access ('public or code-protected') and idempotency_key (recovery behavior), but leaves 'page' unexplained and does not elaborate on project_id/version_id beyond what is obvious. Partial coverage at best.
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 uses a specific verb ('Create or recover') and resource ('durable public or code-protected link for one exact saved version'). It clearly differentiates from siblings like get_version_share_link (retrieval) and revoke_version_share_link (revocation), and specifies the exactness of the version.
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 for when to use the tool: to create or recover a durable link for a specific saved version, with idempotency recovery. It does not explicitly mention alternatives or when-not-to-use, but the context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.