get_upgrade_linkReturn the user's Nepternship Premium checkout link (on nepternship.com) with their price and trial length, or their manage-subscription link if they already subscribe. Use this only when the user explicitly asks to upgrade or asks how to get more intro requests after hitting the free limit.
| Name | Required | Description | Default |
|---|---|---|---|
| join_code | No | The join_code from sign_up, when a new member saved their join answers in this conversation |
Changes observed during successful MCP inspections.
Input schema / properties / join_codeAdded value: +{
+ "description": "The join_code from sign_up, when a new member saved their join answers in this conversation",
+ "type": "string"
+}Input schema / properties / claim_codeRemoved value: -{
- "description": "The claim_code from sign_up or sign_in, if the account is not connected in this conversation",
- "type": "string"
-}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations present, the bar is lower, and the description still adds real behavior context: it returns an external nepternship.com URL, and the result differs depending on whether the user already subscribes. It does not explain what happens if join_code is omitted or how the link is generated, but nothing contradicts readOnlyHint=false / openWorldHint=true.
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: the first establishes what is returned and its branching, the second establishes the trigger. Nothing is repeated from the title and no sentence is filler.
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?
No output schema exists, and the description compensates by describing the payload (link, price, trial length) and its two variants. A minor gap remains around the optional join_code and whether the link is single-use or expiring, but an agent has enough to call it 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 coverage is 100% and the single optional join_code is fully documented there, including its origin (sign_up) and when it applies. The description adds no parameter guidance of its own, 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?
States a specific verb ('Return') and a precisely scoped resource: the Nepternship Premium checkout link with price and trial length, or the manage-subscription link for existing subscribers. The conditional return branches are spelled out, so an agent can distinguish it from every sibling (sign_up, request_balance, send_intro_request) 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?
Explicit gating: 'Use this only when the user explicitly asks to upgrade or asks how to get more intro requests after hitting the free limit.' That names both trigger conditions and an implicit exclusion (other mentions of premium should not trigger it). No alternatives need naming because no sibling produces a checkout link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.