Skip to main content
Glama

login

Authenticate to access Rover pet services, enabling pet sitter searches, booking management, and profile handling through secure email and password verification.

Instructions

Log in to Rover with your email and password. Required before most operations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesYour Rover account email address
passwordYesYour Rover account password

Implementation Reference

  • Handler for the 'login' tool - validates input using LoginSchema, calls browser.login() method, and returns success/failure message based on session state
    case "login": {
      const { email, password } = LoginSchema.parse(args);
      const session = await browser.login(email, password);
      return {
        content: [
          {
            type: "text",
            text: session.isLoggedIn
              ? `Successfully logged in as ${session.email}.`
              : "Login failed. Please check your credentials.",
          },
        ],
      };
    }
  • Zod validation schema for login inputs - validates email format and requires non-empty password
    const LoginSchema = z.object({
      email: z.string().email(),
      password: z.string().min(1),
    });
  • Type definition for RoverSession interface returned by login - contains isLoggedIn boolean and optional userId/email fields
    export interface RoverSession {
      isLoggedIn: boolean;
      userId?: string;
      email?: string;
    }
  • src/index.ts:25-36 (registration)
    Tool registration defining 'login' with name, description, and JSON Schema input schema for MCP protocol
    {
      name: "login",
      description: "Log in to Rover with your email and password. Required before most operations.",
      inputSchema: {
        type: "object",
        properties: {
          email: { type: "string", description: "Your Rover account email address" },
          password: { type: "string", description: "Your Rover account password" },
        },
        required: ["email", "password"],
      },
    },
  • Browser automation helper that navigates to login page, fills credentials, submits form, and verifies successful login by checking URL changes
    async login(email: string, password: string): Promise<RoverSession> {
      const page = this.ensurePage();
      await page.goto(`${this.BASE_URL}/login/`);
      await page.waitForLoadState("networkidle");
    
      await page.fill('input[name="email"], input[type="email"]', email);
      await page.fill('input[name="password"], input[type="password"]', password);
      await page.click('button[type="submit"], input[type="submit"]');
      await page.waitForLoadState("networkidle");
    
      const url = page.url();
      const loggedIn =
        !url.includes("/login") &&
        !url.includes("/signin") &&
        (url.includes("/dashboard") ||
          url.includes("/account") ||
          url === `${this.BASE_URL}/` ||
          !url.includes("login"));
    
      this.session = {
        isLoggedIn: loggedIn,
        email: loggedIn ? email : undefined,
      };
    
      return this.session;
    }
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It mentions that login is required for most operations, implying session establishment, but lacks details on authentication method (e.g., token-based), session duration, error handling, or security considerations. It adds some context but misses key behavioral traits for an authentication tool.

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 two sentences, front-loaded with the core action, and every sentence earns its place by stating the purpose and usage context. There is zero waste, making it highly efficient and easy to parse.

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

Completeness3/5

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

Given no annotations and no output schema, the description is minimal but covers the essential purpose and prerequisite nature. However, as an authentication tool with potential complexities (e.g., session management, errors), it lacks details on return values or behavioral nuances, making it adequate but with clear gaps.

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?

Schema description coverage is 100%, with both parameters (email and password) well-documented in the schema. The description mentions these parameters but doesn't add meaning beyond what the schema provides (e.g., format requirements or examples). 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 ('Log in') and the target system ('Rover'), specifying authentication with email and password. It distinguishes itself from siblings by being the only authentication tool, though it doesn't explicitly name alternatives. The purpose is specific and actionable.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool: 'Required before most operations.' This provides clear context that it's a prerequisite for other tools, guiding the agent to invoke it early in workflows involving Rover operations.

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/markswendsen-code/mcp-rover'

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