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

Annotations provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds behavior: calling with no args returns a link, calling with token validates/uses the token. It states that the token is non-expiring only in config, implying session tokens may expire. It does not mention any side effects like invalidating existing sessions or whether the token is stored. The description is consistent with annotations, but it doesn't go beyond trivial 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 long run-on sentence with multiple clauses and asides ('MCP.AI for IDE agents (Cursor, etc.)', 'Best: add it to this server's config...', 'Or paste it here...'). It lacks structure and is not front-loaded. Key information like the tool's purpose is buried. It could be split into short sentences: 'Authenticate the server with an access token. To get a link, call with no args. To use a session token, pass it as {token: '<jwt>'}. For permanent authentication, add the token to the server config as a header.' This is overly long and unstructured.

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?

The tool has a single optional parameter and no output schema, so the description needs to explain the return behavior and side effects. It does explain the two call modes (with/without token) and the difference between permanent and session login, but it doesn't describe what happens on success or failure, or the format of the response. Given the simplicity, a score of 3 is okay, but it misses details like whether the token is stored in memory or environment, and what the link looks like.

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 has one optional parameter 'token' with no description. The description explains that 'token' is an optional JWT token pasted by the user for session-only login, and calling with no args returns the link. This adds significant meaning beyond the schema, which is minimal. However, with only one parameter and low schema coverage (0%), the description compensates, but it doesn't provide syntax or format beyond saying token is a JWT. A score of 3 is 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?

The description explains the tool's purpose: to authenticate the MCP server with an access token, either permanently via config or session-based via the token parameter. However, it is somewhat verbose and mixes instructions for IDE agents (Cursor, etc.) and mentions 'MCP.AI' which may be ambiguous. The verb is implicit ('log in' and 'call') and the resource (authentication token) is clear, but the description does not explicitly state 'Authenticates the server' and it could be more concise.

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 usage guidance: for permanent authentication, add the token to the server's config as a header; for session-only, call with the token parameter or with no args to get the login link. It tells when to use each approach and implies that the tool is used when the user is not authenticated. There is no explicit 'when not to use', but the two scenarios are well differentiated.

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