Skip to main content
Glama

login

Authenticate with Rotifer Cloud via browser OAuth (GitHub or GitLab) to save credentials locally before using arena_submit or publish_gene.

Instructions

Log in to Rotifer Cloud. Opens the browser for OAuth authorization (GitHub or GitLab). After the user authorizes in the browser, credentials are saved locally. This must be done before using arena_submit or publish_gene.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endpointNoCloud endpoint URL (uses default if omitted)
providerNoOAuth provider (default: github)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.19.1

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden, and it does meaningful work: it discloses an interactive browser-based OAuth flow and that credentials are persisted locally afterward. It omits edge behaviors such as what happens if already logged in or whether existing credentials are overwritten, keeping it at 4 rather than 5.

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?

Four short sentences, each earning its place: purpose, mechanism, side effect, and prerequisite. The critical prerequisite is stated last but nothing is padded or redundant.

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

Completeness4/5

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

With no annotations and no output schema, the description covers the flow, its side effect, and the downstream tools that depend on it. It leaves minor gaps (post-login state, interaction with auth_status/logout), but an agent has enough to invoke it correctly.

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%, so both parameters (endpoint, provider) are already documented. The description only restates the providers ("GitHub or GitLab") without adding syntax, defaults, or endpoint guidance, so the baseline 3 for high schema coverage applies.

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?

States a specific verb and resource ("Log in to Rotifer Cloud") and explains the mechanism (OAuth via GitHub/GitLab). It does not explicitly distinguish itself from the related siblings auth_status or logout, so an agent gets a clear purpose but no direct routing help against those near-neighbors.

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

Usage Guidelines4/5

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

Gives an explicit prerequisite: "This must be done before using arena_submit or publish_gene." That tells the agent when this tool is required. It stops short of stating when NOT to call it (e.g., when already authenticated, check auth_status first), so it is clear context without full exclusion guidance.

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