Skip to main content
Glama

Register Agent

register_agent

Register to dispatch physical-world tasks. No existing account needed. Returns an API key (m2m_...) required for all subsequent tools — store it securely, shown only once. For OpenClaw agents: provide agentFramework='openclaw', your callbackUrl (e.g. http://host:port/hooks), and callbackSecret (your hooks.token). Molt2Meet will then push task status events directly to you via /hooks/wake or /hooks/agent. Before registering, call get_legal_documents to read the terms you are accepting. Requires: nothing. Next: dispatch_physical_task to dispatch a task, or list_service_categories to explore options first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNoOptional: contact email for the agent's owner (for platform communications, not required for registration)
localeNoOptional: your preferred language as a locale slug (e.g. 'en', 'nl', 'de', 'pt-BR'). Must match a slug from list_locales. If omitted, per-request locale falls back to the Accept-Language header. Affects payment pages (Stripe) and future localized responses.
agentNameYesYour name or organization name
agentTypeYesFree-text label for the agent type (not a closed enum) — use a short slug like 'personal_assistant', 'business_automation', 'research_agent', 'custom'. Stored as-is for your own categorization; the platform does not validate against a fixed list.
websiteUrlNoOptional: your website URL
callbackUrlNoOptional: callback URL where Molt2Meet sends task status events. For OpenClaw: your gateway URL + /hooks path (e.g. http://127.0.0.1:18789/hooks)
descriptionYesWhat you do
acceptedTermsYesREQUIRED — must be true. Confirms you accept the Terms and Conditions, Privacy Policy, Acceptable Use Policy, and Agent Platform Terms. Call get_legal_documents first to read the documents you are accepting. Registration is rejected if this is false or omitted.
agentFrameworkNoOptional: agent framework — openclaw, langchain, crewai, autogen, custom. Enables framework-optimized event delivery.
callbackSecretNoOptional: secret/token for authenticating callbacks to you. For OpenClaw: your hooks.token value. Stored encrypted, never exposed.
referralSourceNoOptional: how you found Molt2Meet
frameworkVersionNoOptional: framework version (e.g. 1.2.0)
callbackConfigJsonNoOptional: callback config as JSON. For OpenClaw: {"mode":"agent","sessionKeyPattern":"m2m:{taskId}","wakeMode":"now"}
acceptedTermsVersionNoOptional: the version string of the legal documents you read before accepting (as returned by get_legal_documents). If provided and outdated, registration fails so you can re-read. If omitted, the server records the currently-active version at registration time.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / locale
      Added value: +{
      +  "default": null,
      +  "description": "Optional: your preferred language as a locale slug (e.g. 'en', 'nl', 'de', 'pt-BR'). Must match a slug from list_locales. If omitted, per-request locale falls back to the Accept-Language header. Affects payment pages (Stripe) and future localized responses.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

The description discloses that the API key is shown only once and must be stored securely, and it explains callback behavior for OpenClaw agents. These details add valuable context beyond the annotations, which only indicate non-read-only and non-destructive behavior, without contradicting them.

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?

The description is relatively long but well-structured: it covers purpose, API key security, OpenClaw-specific guidance, a prerequisite legal step, and next steps. Each sentence adds meaningful information, so the length is justified rather than wasteful.

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?

Despite having no output schema, the description explains the return value (API key) and its importance, plus the prerequisite call to get_legal_documents and suggested next actions. For a tool with 14 parameters, this provides a complete enough context for correct invocation, especially since the remaining details are in the schema.

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?

The input schema has 100% description coverage with rich details, so the baseline is 3. The description adds extra guidance for OpenClaw-related parameters (agentFramework, callbackUrl, callbackSecret) with example values, which provides supplementary value and helps the agent select the correct parameters for a specific use case.

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 'Register to dispatch physical-world tasks' with a specific verb and resource. It distinguishes from sibling tools by mentioning the API key returned for subsequent tools, which is unique to registration and not covered by other tools like dispatch_physical_task or get_agent_profile.

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 explicit sequencing: 'Before registering, call get_legal_documents' and 'Next: dispatch_physical_task to dispatch a task, or list_service_categories to explore options first.' This gives clear when-to-use context and next steps, though it does not explicitly state when not to use the tool (e.g., if already registered).

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

A3.9/5.0
Disambiguation3/5

Most tools have clearly distinct purposes, but there are overlapping pairs like fund_wallet and checkout_wallet_deposit (both create checkout URLs for wallet top-up) and cancel_physical_task vs cancel_task_with_settlement. Detailed descriptions and cross-references help, but the sheer number of similar actions creates misselection risk.

Naming Consistency4/5

Tool names follow a consistent verb_noun snake_case pattern (e.g., get_*, list_*, approve_*). Minor deviations include inconsistent use of 'task' vs 'physical_task' in names and the awkward 'checkout_wallet_deposit', but overall the pattern is predictable.

Tool Count2/5

54 tools is excessive for any server, even a complex platform. While each tool has a role, many are redundant or could be consolidated (e.g., wallet funding tools, multiple approval/cancel variations), making the set feel bloated and hard to navigate.

Completeness4/5

The tool set covers the full task lifecycle, escrow/direct settlement flows, wallet management, webhooks, support, and administrative functions. The only notable gap is the inability to update task details beyond location (description, deadline, etc.) after dispatch, but core workflows are well-covered.