Skip to main content
Glama

sign_up

Idempotent

Request a free Recao account for your human. This does NOT create an active account: it registers a PENDING one and emails your human an activation link; nothing works and no terms are accepted until they click it (the human accepts the terms at activation, not you). The API key in the response stays inert until then. Consent stays with the human, so calling this is a request, not a decision made for them: in an interactive session their approval of this tool call is the go-ahead; if you run autonomously, surface this step to your human instead of calling it. After activation, reconnect with header Authorization: Bearer <key>.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesThe account owner's email (the human founder's)
app_nameNoThe user's own app (App Store name), so reports and memory attach to it

TDQS

A4.9/5.0
Behavior5/5

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

Adds significant context beyond annotations, such as the pending nature, inert API key, human consent, and the need to reconnect after activation. Annotations (idempotentHint: true, destructiveHint: false) are consistent with the description.

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?

Despite length, every sentence adds essential information. Well-structured with purpose upfront and no redundancy.

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 no output schema, the description explains the response (inert API key) and post-activation steps, making it complete for a sign-up tool with 2 parameters.

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% with good descriptions; the description adds context like 'human founder's' for email and 'App Store name' for app_name, slightly enhancing clarity beyond the schema.

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 clearly states 'Request a free Recao account for your human' and explains the pending account creation process, distinguishing it from other tools by its specific action.

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?

Explicitly provides when-to-use and when-not-to-use, including guidance for interactive vs. autonomous sessions: 'if you run autonomously, surface this step to your human instead of calling it.' It also clarifies that activation requires human action.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose. The status checkers (assemble_status, clips_status) are differentiated by the job type they monitor. Memory tools (index, note, recall) are distinct operations. Competitor ad tools (search, get ads, get details) and video generation pipeline (avatar, clips, assembly) are well-separated.

Naming Consistency5/5

All tools use consistent snake_case with a verb_noun or noun_verb pattern (e.g., assemble_video, get_competitor_ads, memory_index). No mixing of conventions, making the tool names predictable and easy to understand.

Tool Count5/5

With 17 tools, the server covers account management, memory, competitor research, and video generation without being overwhelming. The count is well-scoped for its functionality, neither too sparse nor too heavy.

Completeness4/5

The toolset covers the core workflows: account setup (sign_up, upgrade, whoami), memory (CRUD), competitor analysis (search, get ads, details), and video ad creation (avatar, clips, assembly). Minor gaps like lacking a delete memory tool are acceptable given the domain focus.