rivian_login

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

Annotations only declare write/open-world/non-destructive, but the description adds substantive behavior: it replaces the current session, persists to ~/.rivian-mcp/session.json, leaves sign-in pending until OTP is submitted, and returns either a signed-in message or a code-sent message plus credential errors. This is exactly the context annotations cannot convey.

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?

Front-loaded with purpose and trigger condition; every sentence carries distinct information (trigger, persistence, OTP flow, returns). It is dense but slightly long, with the return-value sentence arguably recoverable from behavior, so not quite maximal conciseness.

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 no output schema, the description compensates by describing both success and failure return messages and the pending-OTP state. Trigger conditions, credential source, side effects, and follow-up tool are all covered for what is a moderately complex auth operation.

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?

There are zero parameters, and the description explicitly confirms 'Takes no arguments' alongside the fact that credentials come from server configuration (RIVIAN_EMAIL/RIVIAN_PASSWORD) rather than the call. That removes any ambiguity about supplying credentials as inputs.

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+resource ('Sign in to Rivian') and immediately distinguishes itself from the sibling read tools, which all fetch state rather than establish a session. An agent can tell from the first clause that this is the authentication entry point.

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?

Explicitly names the conditions for calling ('when no session is saved or after the session expires') and notes that a saved session is restored automatically on launch, so the agent knows when NOT to call. It also routes the OTP follow-up to rivian_submit_otp by name, covering the alternative path.

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