Skip to main content
Glama
Sign In
exit1-mcp

exit1-mcp

by Mopra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create an exit1 account

create_account

Create a free Exit1 account using the user's email and connect this server so monitoring tools work immediately; Exit1 emails a claim link, and alerts are delivered after the account is claimed.

Instructions

Create a free exit1 account for the user and connect this server to it, so the other tools work right away. Use the user's own email address: exit1 emails it a link to claim the account, and alerts are only delivered once they claim it. Monitors you create before then start running immediately. Fails if the email already has an account; then ask the user for an API key instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "email": "<email>"
    },
    "name": "create_account"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailYesThe user's email address. Ask them if you don't know it.
agent_nameNoHow you identify yourself to the user in the claim email, e.g. "Claude Code".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only supply safety flags (readOnly=false, openWorld=true, idempotent=false, destructive=false). The description adds genuinely non-obvious behavior: an outbound claim email is sent, alerts are suppressed until the user claims, monitors created earlier run immediately, and the call hard-fails on a duplicate email. That is real side-effect disclosure beyond the annotation set.

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?

Roughly sixty words in four sentences, front-loaded with the action and its immediate benefit, then prerequisites, then the failure branch. No filler and no repetition of the schema field text.

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?

With no output schema, annotations covering only safety flags, and full schema coverage on both parameters, the description supplies exactly what is missing: claim flow, alert timing, and the duplicate-email failure mode. Nothing needed to call it correctly is absent.

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 is 3. The description earns a bump by explaining why the email value must be the user's own (exit1 sends the claim link there and alerts depend on claiming it), which is downstream consequence the schema field text does not convey.

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 and resource (create a free exit1 account) plus the second effect (connect this server to it), which no sibling does. It also distinguishes itself from create_check by explaining that monitors may be created before the account is claimed and start running immediately.

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?

Gives the condition for use ('so the other tools work right away'), a prerequisite on whose email to supply ('Use the user's own email address'), and an explicit fallback when it fails ('Fails if the email already has an account; then ask the user for an API key instead'). The when-not path is named rather than implied.

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

Deploy Server

Other Tools