doola

Get Secure SSN Link

request_ssn_entry_link

For a responsible party who lives in the US, gets a one-time link to doola's secure page where the customer, signed in to the same doola account they use here, types the responsible party's Social Security Number for the EIN application. The SSN never passes through you, this chat or any tool: never ask for it here and never accept it if offered. Clients that support URL elicitation are asked to open the page directly; otherwise paste ssnEntryUrl verbatim. The link works once and expires after 15 minutes; call this again for a fresh one. Returns responsiblePartySsnOnFile (never the SSN itself). Refused with PRECONDITIONS_NOT_MET until the responsible party is saved. Takes no arguments.

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": "request_ssn_entry_link"
  }
}

Input Schema

Name	Required	Description
`context`	No	Optional, for analytics only. In one sentence, why you are calling this tool and how it serves the user's goal. Describe the purpose in general terms: never include names, emails, phone numbers, addresses, IDs or any other personal details.
`llm_model`	No	Optional, for analytics only. Your exact model identifier from your system prompt (e.g. "claude-opus-4-8"), or "unknown" if unsure. Never guess.
`conversation_id`	No	Optional, for analytics only. The exact conversation_id from this server's previous response, unchanged. The first response provides one, so leave this out until you have it and never invent one. Keep passing the same value for the rest of the conversation, even when the user moves on to a new request.

Output Schema

Name	Required	Description
`code`	No	Structured error code when error=true (e.g. INVALID_INPUT, PRECONDITIONS_NOT_MET, READINESS_CHECK_FAILED, FILING_FAILED).
`error`	No	true if the call failed
`saved`	No	What this call saved.
`message`	No	Human-readable status.
`missing`	No	Prerequisites still unmet, in flow order. Empty when only filing remains.
`nextStep`	No	The step the formation flow now waits on; null once formation is complete.
`companyId`	No	The company the call acted on.
`companyName`	No	Name of the company the call acted on. Name it to the user.
`ssnEntryUrl`	No	doola's secure SSN page for the responsible party. Paste it verbatim.
`nextQuestion`	No	The customer-facing question for nextStep; null once formation is complete.
`conversation_id`	No	This conversation's handle. Pass it unchanged as conversation_id on every later call.
`expiresInMinutes`	No	Minutes until ssnEntryUrl stops working.
`responsiblePartySsnOnFile`	No	Whether doola has the responsible party's SSN. Never the SSN itself.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 5, 2026

changedOutput schema / properties / message / description

Previous value: -"Human-readable status or instruction."New value: +"Human-readable status."

removedOutput schema / properties / nextAction

Removed value: -{
-  "description": "Imperative for the agent — follow verbatim.",
-  "type": [
-    "string",
-    "null"
-  ]
-}

removedOutput schema / properties / nextActionInput

Removed value: -{
-  "description": "{tool, arguments} template for the next call. Replace every <placeholder> in arguments with the user's real answer.",
-  "type": [
-    "object",
-    "null"
-  ]
-}

changedOutput schema / properties / nextQuestion / description

Previous value: -"Question to ask the user verbatim before the next call."New value: +"The customer-facing question for nextStep; null once formation is complete."

changedOutput schema / properties / nextStep / description

Previous value: -"The tool to call next; null when the flow is complete."New value: +"The step the formation flow now waits on; null once formation is complete."

addedOutput schema / properties / nextStep / properties

Added value: +{
+  "description": {
+    "description": "Where the customer stands at this step and what their options are.",
+    "type": "string"
+  },
+  "missingFields": {
+    "description": "Arguments of that tool the step still needs.",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  "tool": {
+    "description": "The tool that records this step.",
+    "type": "string"
+  }
+}

changedOutput schema / properties / nextStep / type

Previous value: -[
-  "string",
-  "null"
-]New value: +[
+  "object",
+  "null"
+]

AddedNov 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes far beyond the annotations: it discloses that the link is single-use, expires in 15 minutes, and must be re-requested; that the SSN never passes through the agent or chat; the refusal code and its condition; and the `responsiblePartySsnOnFile` return field. The annotations only say readOnly=false / destructive=false / openWorld=false, so this description is carrying the real behavioral load.

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?

Front-loads what the tool does, then layers the security constraint, client-handling rule, expiry, return value, and precondition in short declarative sentences. Every sentence carries operational information; nothing is 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 zero-argument, precondition-gated tool with an output schema, the description supplies everything an agent needs: when it becomes callable, what to do with the URL, how long it lasts, what is returned, and the hard prohibition on handling the SSN directly.

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 coverage is 100%, so the three optional analytics parameters (context, llm_model, conversation_id) are already fully documented, and there is no parameter meaning left for the description to add. The closing "Takes no arguments" slightly understates the presence of those optional fields, but since they are explicitly analytics-only and optional, the baseline 3 applies rather than a penalty.

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 ("gets a one-time link" to a secure SSN entry page) and pins down exactly what the tool is for: the responsible party entering their SSN for the EIN application. None of the siblings (create_checkout_session, submit_formation, etc.) overlap with this capability, so an agent can place it immediately.

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 clear triggering context (responsible party residing in the US, EIN application in progress) and an explicit precondition: it is refused with PRECONDITIONS_NOT_MET until the responsible party is saved. It also prescribes behavior based on client capability (URL elicitation vs. pasting `ssnEntryUrl`). It stops short of naming an alternative tool, but no sibling covers this path, so the only real gap is the absence of explicit "do not use when" framing.

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

All doola tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.