Skip to main content
Glama
usewrit

writ-mcp

Official
by usewrit
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Use the user's saved sign-ins

writ_personas

List, inspect, sign in, or record login workflows for saved website personas to run tasks as the user without passwords. Request or wait for new persona links before asking for credentials.

Instructions

The user's OWN accounts on websites. When a task needs them signed in (their email, social, shop, bank or work portal), a persona is how Writ signs in as them: no password passes through this tool or the conversation, so never ask for one. A persona is a saved sign-in identity: a site's username plus credentials sealed server-side (never readable here), optional 2FA whose codes are minted server-side, and a warm signed-in session. USE one by passing its persona_id to writ_browser_use, writ_crawl_site, writ_scrape or writ_run_workflow. BEFORE asking the user for credentials for a site, call action='list' (filter by domain). action='get' inspects one (include_runs adds its recent runs); action='sign_in' runs its login workflow NOW (force=true re-logs-in even when the session looks usable); action='record_login' has a server-side AI sign in as it once and RECORD the flow as its login workflow, so it can always sign itself back in. NONE FITS? This tool can NOT create a persona and no credential ever passes through it. list with a domain answers persona_needed: a tell_user, a create_url (a MINTED link: a small Writ window with only the persona form, pre-filled for that site) and its link_id; action='request' domain= mints one on purpose (another account for a site). Relay it BEFORE starting the task, then action='wait' link_id=: ONE held call that answers the moment the user saves it, with the persona_id — continue on your own. ALSO LISTED: the personas of the user's linked Writ DESKTOP (source='device', id device:<agent>:<id>, name and site only). Pass that id as persona_id to writ_run_workflow, writ_browser_use / writ_record_website, writ_scrape or writ_crawl_site: the work goes to that desktop, which signs in from its own vault and only on the persona's own site - the credentials never leave it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
whyNorequest: one line the user sees in the window — what you need the account for.
waitNolist + domain: hold up to 75s for a persona for that site to appear. With a link_id prefer action='wait'. Never poll in a loop instead.
forceNosign_in: re-run the login even when the current session still looks usable.
actionYesWhat to do (default list). request = mint the persona link for a site (domain); wait = hold until the user saves it (link_id).
domainNolist: only personas usable on this host (suffix match), e.g. 'github.com'. With no match the answer is `persona_needed` — the ask to relay to the user. request: the site the new persona is for.
link_idNowait: the `link_id` of a persona_needed / request answer. Holds up to 75s and answers the moment the user saves the persona (persona_id), declines, or closes the window; `still_waiting` means call it again.
login_urlNorecord_login: exact sign-in page URL when known; defaults to the persona's domain root (the AI finds the form from there). list / request: the site's sign-in page, carried into `create_url` so the new persona can record it.
persona_idNoWhich persona — required for get / sign_in / record_login.
include_runsNoget: include the persona's recent runs (which workflows acted as it, and whether they succeeded).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond annotations: no password passes through the tool or conversation, credentials are sealed server-side and never readable, 2FA codes are minted server-side, sessions are warmed, wait holds up to 75s and answers on save/decline/close, and desktop personas sign in from their own vault only on their own site. This is rich operational context that annotations (openWorld, not read-only) do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is valuable and the action-routing is front-loaded, but it is a dense wall of run-on, heavily-bolded sentences that mix definitions, workflows, and return shapes. Some of the length is justified by six actions, yet it is harder to parse than it needs to be.

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?

For a 9-parameter, six-action tool with no output schema, the description does the heavy lifting by describing return keys (persona_id, link_id, still_waiting, persona_needed with tell_user/create_url). It is nearly complete, though the response shapes could be stated slightly more cleanly.

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, but the description adds cross-parameter semantics the schema does not: the request→link_id→wait→persona_id workflow, that domain does suffix matching and yields persona_needed, and that link_id answers with persona_id/still_waiting. This meaningfully enriches how the parameters relate.

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?

The description defines the resource precisely (a 'saved sign-in identity' with sealed credentials) and enumerates the concrete actions (list, get, sign_in, record_login, request, wait). It also distinguishes itself from siblings by naming the tools it feeds (writ_browser_use, writ_crawl_site, writ_scrape, writ_run_workflow), so an agent can tell what it is and how it connects to the ecosystem.

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?

Explicit routing is given: use persona_id in the sibling tools, call action='list' (filtered by domain) BEFORE asking the user for credentials, use 'sign_in' to run the login now, 'record_login' to capture a workflow, and 'request'/'wait' to mint and hold for a new persona. It even states what the tool cannot do ('can NOT create a persona') and warns against polling loops.

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