Skip to main content
Glama

Create Agent

ethora-agents-create-v2

Create a configurable AI agent persona for Ethora chat, defining its name, avatar, system prompt, and reply behavior (response mode, cooldown) for use in single or multi-agent rooms.

Instructions

Create a reusable AI agent (POST /v2/apps/:appId/agents). Works in user auth mode (the normal hosted mode) or B2B mode; app-token mode is not accepted by the backend. Each agent is a persona — name, avatar, system prompt, LLM config, plus response-gate settings (responseMode, cooldownSec) that control when it speaks in a room. For multi-agent scenarios (two or more personas conversing in one chat) create each one separately, then ethora-agent-invite-to-chat them into the same room. See the ethora-agents-quickstart prompt for the end-to-end recipe. Requires: a selected app (ethora-app-select) or an explicit appId; the agent is owned by that app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoShort display name. For multi-agent scenarios, prefer single-word names (e.g. 'Hannibal', 'Varro') — the @-mention matcher uses the exact display name with word-boundary matching.
slugNoURL-safe slug (auto-generated from name if omitted).
appIdNo24-char hex appId the agent belongs to (`POST /v2/apps/:appId/agents`). Defaults to the app selected with `ethora-app-select`. Pass it when you just created an app so the agent lands there rather than in the token's own app.
isRAGNoEnable retrieval-augmented generation from indexed sources.
promptNoSystem prompt — the agent's persona, role, style of speech, and behaviour rules. For multi-agent scenarios, instruct the agent to end every message with an @-mention of who speaks next; that's how turn-handoff works through the response gate.
ragTagsNoOptional RAG tag filter — restrict retrieval to sources matching these tags.
summaryNoShort bio shown in agent lists.
triggerNoLegacy trigger field. Prefer the newer `responseMode` for new agents.
llmModelNoLLM model override (e.g. 'gpt-4o-mini').
flowsYamlNoDeterministic scripted conversation for this agent, as YAML. Drives the agent through a fixed sequence (opening menu, appointment request, intake questionnaire, survey) instead of leaving every turn to the model. Compiled and validated server-side on save: an invalid script is rejected with code `FLOWS_INVALID` and per-line details, and nothing is stored. A flow named `start` is reserved and fires when a conversation opens. Buttons are authored here (`buttons:` on a `say` step, or `options:` on an `ask` step). Call `fetch` with id `doc:agent-flows` for the full authoring format before writing one. Pass an empty string to clear the script.
categoriesNoFree-form category tags for agent directory listings.
visibilityNo'private' (only invitable inside the owning app) or 'public' (cross-app invitable).
cooldownSecNoMinimum seconds between this agent's replies in a given room. Damped 2x for bot-to-bot. Set 0 for quick turn-taking in multi-agent scenarios.
isPublishedNoConvenience alias for setting visibility='public'.
llmProviderNoLLM provider override (e.g. 'openai'). Defaults to the app's configured provider.
botAvatarUrlNoURL of the avatar image shown next to bot messages.
responseModeNoWhen the agent decides to reply. 'always' = every room message; 'mentioned' = only when @-mentioned by display name or via /bot (recommended for multi-agent turn-taking); 'smart' = a mini LLM gate decides per-message; 'probability' = coin-flip per message using `responseProbability`.
botDisplayNameNoDisplay name used inside the chat UI. Defaults to `name`.
greetingMessageNoOptional message the agent posts when it first joins a room.
responseProbabilityNoIf responseMode='probability', odds (0-1) of replying to each message. Damped 0.6x for bot-to-bot messages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv26.9.3

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already indicate readOnly=false and openWorldHint=true, and the description adds significant behavioral context beyond them: auth-mode restrictions, backend rejection of app-token mode, agent ownership by app, server-side compilation and rejection of invalid flowsYaml with nothing stored, and the reserved flow name 'start'. It does not contradict the annotations.

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 dense but well-structured: endpoint and auth constraints are front-loaded, the persona/response-gate concept is summarized, the multi-agent workflow is routed to the right sibling, and the prerequisite is stated at the end. Every sentence earns its place without 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?

Given the tool's high complexity — 20 parameters, multi-agent behavior, auth modes, and flowsYaml validation — the description covers prerequisites, exclusions, multi-agent recipe, and backend validation behavior. The absence of an output schema is not a material gap here because the creation behavior and parameter semantics are fully described.

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%, so the baseline is 3. The description adds cross-parameter meaning by grouping fields into persona settings, LLM config, and response-gate settings, and by connecting responseMode/cooldownSec to room behavior and multi-agent turn-taking. This goes slightly beyond the individual schema descriptions, though the schema already carries the bulk of the burden.

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 opens with a specific verb and resource: 'Create a reusable AI agent (POST /v2/apps/:appId/agents).' It clearly distinguishes the create operation from siblings like ethora-agents-update-v2, ethora-agents-list-v2, and ethora-agent-invite-to-chat by focusing on creation and persona configuration.

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 states when this tool is appropriate: create agents, one per persona, and for multi-agent scenarios create each separately then use ethora-agent-invite-to-chat. It also gives a prerequisite ('Requires: a selected app... or an explicit appId') and an exclusion ('app-token mode is not accepted by the backend'). This is strong usage routing.

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

Deploy Server

Other Tools