Skip to main content
Glama

Entrar no Aspa

aspa_login

Opens a visible Chrome window so the user can log in to the Aspa panel directly; credentials are never passed, then run the setup check to confirm access.

Instructions

Open a visible Chrome window on the Aspa panel so the user logs in themselves (5 minute limit). Returns as soon as the window is open; tell the user to log in there and then call aspa_setup_check to confirm. Credentials are never passed through this tool.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aspa_login"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.0

TDQS

A4.1/5.0
Behavior4/5

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

Adds behavior the readOnlyHint annotation does not convey: a visible browser window, a 5-minute time limit, and immediate return once the window is open rather than waiting for login. It also makes the security-relevant point that credentials never pass through the tool. The gap is what happens when the 5-minute limit expires or the user closes the window.

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 short sentences, front-loaded with what happens, then the return behavior, then the required next step. Every sentence carries information an agent needs and none is padding.

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 output schema and no parameters, the description covers the essentials: what opens, how long it lasts, when it returns, and what to do next. It is incomplete only on the failure path, where the user does not log in within five minutes and the agent needs to know whether to retry via aspa_reopen or report failure.

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?

The tool takes zero parameters, so the schema carries no semantics to supplement and the baseline applies. The description correctly implies a parameterless, fire-and-forget call by saying it returns as soon as the window opens.

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 concrete action and resource: it opens a visible Chrome window on the Aspa panel for interactive user login. This is far more specific than a restatement of the name. It falls short of 5 because it never distinguishes itself from the sibling aspa_reopen, which an agent could plausibly confuse with this tool.

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 a clear condition for use (the user logs in themselves rather than the agent handling credentials) and an explicit follow-up step: 'tell the user to log in there and then call aspa_setup_check to confirm.' It does not state when this tool is unnecessary, e.g. if a session already exists or if aspa_setup_check already passes, so it stops short of naming exclusions.

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