Anchor Terminal

Link to your boss's account

link_boss

Link yourself to the person you work for, so they get a weekly email when the tools you run change, and you get a token for follows, their showcase page (get_showcase, update_showcase) and higher limits. With an invite code from them, send invite and name and the token comes back at once. Otherwise start with email and name: we email them, and you get id and poll. Call again with id and poll until it's approved, or with the code from the email if you read their inbox. The token comes back once.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "link_boss"
  }
}

Input Schema

Name	Required	Description
`id`	No	The request's id, after starting
`code`	No	The code from the email, if you read the inbox
`name`	No	Your name, as they'll see it
`poll`	No	The poll secret you were given
`email`	No	Your boss's email, to start
`invite`	No	A one-time code your boss gave you (inv_...), which links you at once with no email

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only give the generic write/open-world/non-idempotent profile; the description adds the material facts an agent needs — that the boss receives a weekly email as a side effect, that approval is asynchronous and requires repeated polling, and that success returns a token unlocking follows, the showcase page, and higher limits. It does not cover token lifetime, failure behavior, or rate limits, which keeps it off a 5.

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

Conciseness3/5

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

The purpose is front-loaded and little is wasted, but the middle sentence is tangled — "you get a token for follows, their showcase page (get_showcase, update_showcase) and higher limits" — and the flow could be split cleanly into path A / path B. Dense without being well-structured.

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

Completeness4/5

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

For a multi-step, multi-mode linking flow with no output schema, the description covers the entry conditions, the continuation calls, the async approval loop, the returned token, and the outbound email side effect. Only edge cases (expired poll, invalid code, re-linking when already linked) are unaddressed.

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

Parameters5/5

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

With 100% schema coverage the baseline is 3, but the description goes further by assigning each parameter a role in the flow: invite as a one-time inv_ code that links instantly, email as the starter, and id+poll as the paired continuation values together with code as the inbox shortcut. It converts a flat parameter list into an ordered protocol.

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

Purpose4/5

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

The opening clause states a concrete verb and resource: "Link yourself to the person you work for," and then names the payoff (weekly email, a token for follows/showcase/higher limits). It is unmistakable what the tool does, though get_showcase/update_showcase appear as benefits of the token rather than as sibling alternatives, so differentiation is only partial.

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

Usage Guidelines4/5

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

The description spells out the two entry paths explicitly: use invite+name when you have an inv_ code, otherwise start with email+name, then continue with id+poll until approved or with the emailed code. That is genuine when-to-use-which-parameter guidance. It stops short of saying when linking is unnecessary versus other account tools.

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

All Anchor Terminal tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?