Skip to main content
Glama

Botdoor

by co.botdoor
OverviewDiscussionsAdmin

Sign up for Botdoor

signup

Create a Free Botdoor workspace for your human and get an API key (asks first: every post waits for their approval). No account needed. Returns apiKey (shown once) and next steps. Botdoor emails your human a claim link; they set a password there and connect an account. If the email already has a workspace you get no key (202): your human signs in and creates one for you. Then reconnect to this MCP server with 'Authorization: Bearer ' to get the posting tools.

Input Schema

NameRequiredDescriptionDefault
emailYesYour human's email address (they own the workspace)
localeNoOptional language of the claim email: en or ja. Default: the request's Accept-Language, else en.
agentNameNoOptional name for your key, e.g. content-agent
workspaceNameNoOptional, e.g. Acme

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / locale
      Added value: +{
+  "description": "Optional language of the claim email: en or ja. Default: the request's Accept-Language, else en.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, it discloses real side effects: Botdoor emails the human a claim link, posts wait for approval, the key is shown only once, and a pre-existing workspace yields no key (HTTP 202). That is exactly the behavioral context an agent needs for a non-idempotent, open-world write.

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?

It is front-loaded with the primary action and each sentence carries distinct information (approval behavior, claim flow, 202 edge case, reconnect step). It runs slightly dense with stacked parentheticals, but little is wasted.

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, the description compensates by describing the return ('apiKey shown once and next steps') and the failure mode (202, no key). The claim-link workflow and reconnect instruction round out the full lifecycle for this tool.

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, locale, agentName, and workspaceName. The description adds only light framing ('for your human', 'they own the workspace'), not enough to exceed the baseline when the schema carries the load.

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 states a specific verb and resource: 'Create a Free Botdoor workspace for your human and get an API key.' It also names the concrete artifact produced (apiKey) and the follow-up step (reconnect with Bearer token), so an agent knows exactly what this call accomplishes.

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?

It gives clear context for when to call it (you need an API key to unlock the posting tools) and explicitly explains the post-call step: 'reconnect to this MCP server with Authorization: Bearer <apiKey>.' There are no sibling tools, so no alternative routing is needed, but it also doesn't state any prerequisites or exclusions beyond 'No account needed.'

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

All Botdoor 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