Skip to main content
Glama

Sign in to Overleaf

sign_in

Authenticate with Overleaf once so every other tool can access your projects, opening the login page in a browser or accepting a session cookie you supply.

Instructions

Signs in to Overleaf so the other tools work. Without a cookie it opens the Overleaf login page in a browser window on this computer (Google, ORCID, institutional SSO and passwords all work) and waits for the person to log in. If the person gives you their overleaf_session2 cookie, pass it instead. Only needed once; the session is shared by every Overleaf tool on this computer.

Input Schema

NameRequiredDescriptionDefault
cookieNoSession cookie value (or a whole Cookie header) the person supplied
serverNoSelf-hosted Overleaf URL; default https://www.overleaf.com

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare openWorldHint and destructiveHint, so the description carries the behavioral load and does so well: it discloses the interactive browser-window flow, that it waits for a human, the supported login methods, and that the resulting session persists and is shared across all Overleaf tools on the machine. These are non-obvious traits an agent must anticipate.

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?

Three sentences, front-loaded with purpose and the prerequisite relationship, then the two usage branches. Every sentence earns its place with no filler.

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

Completeness5/5

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

For a 2-param, zero-required auth tool with no output schema, the description covers the interaction model, the cookie alternative, one-time use, and session scope. An agent has everything needed to call it correctly and to instruct the user.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine meaning beyond the schema: it tells the agent when to supply cookie instead of triggering the browser flow, and notes the cookie may be a full Cookie header. It adds little for server beyond the schema's default note.

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

Purpose5/5

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

States a specific verb+resource (signs in to Overleaf) and immediately frames its role among siblings: 'so the other tools work.' An agent can tell this is the authentication prerequisite for the other Overleaf tools rather than a data operation.

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?

Explicitly says when to use it ('only needed once'), gives the alternative path when a cookie is available ('If the person gives you their overleaf_session2 cookie, pass it instead'), and describes the default flow when no cookie is given. Nothing is left to inference.

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