Skip to main content
Glama

Emero

by io.github.EmeroAI
OverviewDiscussionsAdmin

Ask the user to upload a file

request_upload

Show the user an upload card so they can add their OWN image or video (use this only for a genuine human upload — e.g. their client couldn't hand a file to ingest_url). Returns an upload:<id>. Ask them to upload and click Done, then WAIT for their reply — don't poll. When they're done, pass upload: STRAIGHT into generate (reference_image_ids / start_frame_id / end_frame_id) or into view to see it — emero resolves it to the full-resolution file(s). Do NOT call request_upload again for the same file (a second call re-shows the card).

Input Schema

NameRequiredDescriptionDefault
project_idNoOpaque per-chat project id: "p-" plus 6 random letters and digits. Every chat is a new project. Mint one on your first emero call and pass that SAME id on every call in this chat. Never mint a second one in the same chat, even for a new topic, campaign or subject. Only when the user asks to continue an earlier project, reuse its id from get_emero_brain's project list.
project_nameNoShort human title for the project (2-5 words from the user request, e.g. "Perfume ad campaign"). Pass it on your first generate/ingest_url so the project is not left "Untitled". You may also rename at will later — pass an updated project_name (on a generate/ingest_url, or on set_settings with no other change) whenever the user asks, e.g. "call this project cats".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Opaque per-chat project id. Mint one on your first emero action, pass that SAME id every call. One project per chat: NEVER mint a second for a new topic/campaign/subject/vibe — all stay in the one project; a new id is only for a new chat (server folds a stray id back in). A new chat the user says continues an earlier project reuses that project's id (from get_emero_brain's project list)."New value: +"Opaque per-chat project id: \"p-\" plus 6 random letters and digits. Every chat is a new project. Mint one on your first emero call and pass that SAME id on every call in this chat. Never mint a second one in the same chat, even for a new topic, campaign or subject. Only when the user asks to continue an earlier project, reuse its id from get_emero_brain's project list."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses the upload-card interaction, the returned upload:<id>, the need to wait for the user, the lack of polling, and the fact that a second call re-shows the card. It also explains that emero resolves the token to full-resolution files.

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 a single tight paragraph that front-loads the purpose and then flows into usage, waiting behavior, downstream token handling, and the no-repeat warning. Every sentence adds operational value with no filler.

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?

Although there is no output schema, the description states the return value ('upload:<id>') and explains how to use it in generate or view. Despite the absence of annotations, it covers the key interactive and idempotency behavior an agent needs to call it correctly.

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 both project_id and project_name are already fully documented in the schema. The description adds no parameter-specific semantics beyond the schema, which is acceptable at this coverage level but does not exceed the baseline.

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?

States a specific action (show an upload card) and resource (the user's own image or video), and explicitly distinguishes this from ingest_url by limiting it to genuine human uploads. An agent can tell it apart from sibling tools such as generate, view, and ingest_url without opening their schemas.

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?

Gives explicit when-to-use guidance ('only for a genuine human upload — e.g. their client couldn't hand a file to ingest_url'), instructs the agent to wait rather than poll, says where to pass the resulting upload:<id>, and warns against calling it again for the same file.

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

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