Skip to main content
Glama

rivian_submit_otp

Submit verification codes to complete Rivian account authentication and access vehicle monitoring tools.

Instructions

Complete Rivian sign-in with the verification code sent to your phone or email.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
otp_codeYesThe verification code

Implementation Reference

  • mcp-server.js:426-450 (registration)
    Tool registration for 'rivian_submit_otp' - defines the tool name, description, input schema (otp_code parameter), and the async handler that orchestrates OTP validation by calling rivian.validateOtp() and saving the session.
    server.tool(
      'rivian_submit_otp',
      'Complete Rivian sign-in with the verification code sent to your phone or email.',
      { otp_code: z.string().describe('The verification code') },
      async ({ otp_code }) => {
        const email = process.env.RIVIAN_EMAIL;
        if (!email) {
          return text('RIVIAN_EMAIL is not configured.');
        }
    
        if (!rivian.needsOtp()) {
          return text('No pending verification. Start with rivian_login first.');
        }
    
        try {
          await rivian.validateOtp(email, otp_code);
          saveSession();
          return text('Signed in to Rivian successfully.');
        } catch (err) {
          return text(
            `Verification failed: ${err.message}. You may need to start over with rivian_login.`,
          );
        }
      },
    );
  • Core implementation of validateOtp function - executes GraphQL mutation LoginWithOTP to verify the OTP code with Rivian's API, stores the returned access/refresh/user session tokens, and clears the otpToken after successful validation.
    export async function validateOtp(email, otpCode) {
      const data = await gql(
        GRAPHQL_GATEWAY,
        {
          operationName: 'LoginWithOTP',
          query: `mutation LoginWithOTP($email: String!, $otpCode: String!, $otpToken: String!) {
      loginWithOTP(email: $email, otpCode: $otpCode, otpToken: $otpToken) {
        __typename
        ... on MobileLoginResponse {
          __typename
          accessToken
          refreshToken
          userSessionToken
        }
      }
    }`,
          variables: { email, otpCode, otpToken },
        },
        { 'Csrf-Token': csrfToken, 'A-Sess': appSessionToken },
      );
    
      accessToken = data.loginWithOTP.accessToken;
      refreshToken = data.loginWithOTP.refreshToken;
      userSessionToken = data.loginWithOTP.userSessionToken;
      otpToken = '';
    }
  • needsOtp helper function - checks if an OTP token is currently pending, used by the tool handler to determine if a verification is waiting for completion.
    export const needsOtp = () => !!otpToken;
    export const isAuthenticated = () => !!accessToken;
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool completes sign-in, implying a write/mutation operation that likely changes authentication state, but doesn't disclose critical details like whether it requires prior steps (e.g., calling 'rivian_login'), error handling, or what happens on success (e.g., session creation).

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and includes essential context about the code source, making it highly concise and well-structured.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after submitting the OTP (e.g., returns session tokens, errors on invalid code), prerequisites, or integration with sibling tools like 'rivian_login'. Given the complexity of authentication flows, more context is needed for effective agent use.

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

Parameters3/5

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

The schema description coverage is 100%, with the parameter 'otp_code' well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'verification code sent to your phone or email', which provides context but no additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.

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 description clearly states the action ('Complete Rivian sign-in') and the resource ('with the verification code'), specifying it's for completing authentication after receiving a code. However, it doesn't explicitly differentiate from sibling tools like 'rivian_login', which likely initiates the sign-in process.

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

Usage Guidelines3/5

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

The description implies usage context by mentioning 'verification code sent to your phone or email', suggesting this tool is used after receiving an OTP. However, it lacks explicit guidance on when to use this versus 'rivian_login' or other alternatives, and doesn't specify prerequisites or exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PatrickHeneise/rivian-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server