Skip to main content
Glama

MERA Robotics

by com.merarobotics
OverviewDiscussionsAdmin

MERA Robotics: inquiry form

open_inquiry_form
Read-onlyIdempotent

Shows an inquiry form for MERA Robotics in the chat, prefilled with details the person already gave (service, robot, date, place, goal, name, e-mail). It sends nothing by itself: the person checks the details, ticks consent and clicks "Send inquiry" in the form. Use it when someone wants to ask MERA about a date, a rental, a purchase or a deployment. If the host cannot show the form, collect the details in the chat and use request_quote after the person agrees.

Input Schema

NameRequiredDescriptionDefault
cityNoOptional prefill. City or venue of the event or deployment.
langNoLanguage of labels and descriptions: "pl" when the person writes in Polish, otherwise "en". Fact texts stay in their canonical Polish wording.en
nameNoOptional prefill. Full name of the person sending the inquiry, exactly as they gave it.
emailNoOptional prefill. The person’s own e-mail address; the MERA team replies to it. Never guess it or use a placeholder.
robotNoOptional prefill. Optional robot key from list_robots. For rental with an operator only g1 or h2; other keys are for purchase.
companyNoOptional prefill. Company or organisation, if the person gave one.
countryNoOptional prefill. Country of the event or deployment.
messageNoOptional prefill. The goal and what the robot should do, venue conditions and anything else the MERA team should know, in the person’s words.
serviceNoOptional prefill. What the inquiry is about: events = a humanoid robot with a MERA operator at an event; purchase = buying a Unitree robot; integration = a robot deployed in a business (showroom, reception, booth); mera-os = MERA OS conversation software for a robot the person already owns; campaign = Edward Warchocki or a branded robot in a marketing campaign; media = interview or editorial request.
audienceNoOptional prefill. Approximate number of guests or participants.
durationNoOptional prefill. How long the robot should be on site, e.g. "4 h" or "2 days".
languagesNoOptional prefill. Languages the robot should speak with guests, e.g. ["Polish", "English"].
event_dateNoOptional prefill. First day of the event or the preferred start date (YYYY-MM-DD), if known.
reply_languageNoOptional prefill. Language the person wants the reply in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description explains the interaction model: the form is prefilled, the person reviews details, ticks consent, and clicks Send inquiry. It also clarifies that the tool sends nothing by itself, which is important context for a form-display tool.

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?

The description is three focused sentences with no waste. The action, the no-send behavior, the use case, and the fallback are all front-loaded and easy to scan.

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 form-display tool with fourteen optional parameters, full schema coverage, and no output schema, the description covers the interaction sufficiently. It explains what appears, what the user must do, and what to do if the host cannot render the form.

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 all fourteen optional prefill fields are already well documented. The description lists some prefilled details but does not add meaningful syntax or constraints beyond what the schema provides, so baseline 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 description states a specific verb and resource: it shows an inquiry form for MERA Robotics in the chat, prefilled with known details. It also immediately clarifies that the tool itself sends nothing, which distinguishes a form-display action from the submission 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?

It explicitly says when to use the tool: when someone wants to ask MERA about a date, rental, purchase, or deployment. It also gives a concrete fallback path: if the host cannot show the form, collect details and use request_quote after agreement.

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

All MERA Robotics 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