Skip to main content
Glama

dialogbrain

by io.github.saloprj
OverviewDiscussionsAdmin

onboarding_start_signup

🚪 Start a person's own DialogBrain account without a password.

Creates the account if the email is new (it keeps no password, like a Google sign-in), mails a 6-digit sign-in code to that address, and returns the link to send them. Use it for a lead who ASKED to try the product themselves, or who ticked 'create my account' on a form — never for someone who did not ask.

Tell them the code is in the email and give them the returned link: they enter the code and land on the screen that connects their channel. Do NOT ask them for a password and do not send one; there is none. The code is not returned to you, so you cannot read it out — if they say it never arrived, call again after a minute (a second call inside 60s is refused with rate_limited).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesThe address the person gave. The code goes here, nowhere else.
channelNoThe channel they want to run their agent on (e.g. 'whatsapp', 'telegram', 'instagram'), usually the one they picked on the form. It decides which connect dialog the returned link opens.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations (which only declare a non-readonly, open-world write): it discloses the passwordless model, that the code is mailed but never returned to the caller, that a second call within 60s is refused with rate_limited, and that no password exists to ask for. These are exactly the behavioral traits an agent needs and cannot get from the structured fields.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence and the subsequent sentences are dense operational guidance (code delivery, link handoff, retry behavior) rather than filler. It is somewhat long and the emoji is decorative, but almost every sentence earns its place.

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?

Though there is no output schema, the description explains what comes back (the link to send) and how to handle the non-returned code, and it covers the auth model, rate-limit behavior, and the post-signup handoff screen. An agent has everything needed to call this correctly and instruct the user.

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 the schema already documents email (code destination), channel (which connect dialog opens), and in_workspace (single-call workspace override). The description reinforces the email/code relationship but adds little parameter-level meaning the schema lacks, so the baseline of 3 is appropriate.

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 first line states a specific verb+resource ('Start a person's own DialogBrain account without a password') and the body elaborates exactly what happens: creates the account if the email is new, mails a 6-digit code, and returns a link. This is a passwordless signup flow that is unmistakably distinct from sibling tools like workspace_invite or agents_create.

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?

Provides an explicit when ('a lead who ASKED to try the product themselves, or who ticked create my account on a form') and a clear when-not ('never for someone who did not ask'), plus operational guidance for retries after 60s. It stops short of naming the alternative tool to use for people who did not ask, which is the only gap.

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

All dialogbrain toolsInspect
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.

Resources