Skip to main content
Glama

Genaya

Ask Genaya AI to prepare a change

genaya_act
Destructive

Run Genaya AI on one request that may CHANGE something (a task, client, lead, appointment, estimate or invoice draft, expense, a reschedule, cancel or complete, a text or email) as the connected member. Nothing runs here: each proposal comes back in actions with its preview and body_hash. confirm_channel in_chat means the member confirms in this chat (an elicitation, or confirm_action with the body_hash); genaya_page means show confirm_url and stop - the member confirms on a Genaya page. status needs_info means ask the member for needs_info and call again with everything in one message. Money, billing, roles, phone numbers and automations are not available here, and neither is creating an image or a video. One call is 10 Genaya AI credits when it only answers and 20 when it prepares a change; same input rules as ask_genaya.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "message": "<message>"
    },
    "name": "genaya_act"
  }
}

Input Schema

NameRequiredDescriptionDefault
entityNoA record to focus on, taken from an earlier answer's sources (collection and id). Never invented.
messageYesOne question, in plain language, with its period or filter spelled out (today, this week, last month, a client's name). Never two questions in one message.
conversation_idNoThe conversation_id from an earlier answer in this session, to continue that thread (a follow-up about the same records). Leave it out for a new standalone question.
idempotency_keyNoA fresh 16 to 64 character key per question; a retry with the same key replays the finished answer instead of running (and metering) again.

Output Schema

NameRequiredDescriptionDefault
trustYes
actionsYes
receiptNo
replayedNo
confirm_urlNo
needs_humanYes
wants_actionYes
answer_markdownYes
conversation_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations give readOnly=false, destructive=true, openWorld=true, idempotent=false, but the description adds the crucial nuance they cannot convey: "Nothing runs here" — the call only produces proposals in actions with a preview and body_hash, and execution is a separate confirmation. It also discloses cost (10 credits for an answer, 20 for a prepared change) and the retry/replay semantics. It does not describe pagination or what an empty actions array means, so it stops short of a 5.

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?

No throwaway sentences — scope, side-effect model, confirmation routing, error state, exclusions and cost each appear once, and the most important fact ("Nothing runs here") is front-loaded. The middle sentences run long and stack several branches together, which costs some scannability.

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 destructive, open-world, metered tool with a nested entity object and an output schema, the description covers everything the agent needs to decide and act: what is prepared vs executed, how confirmation is handled per channel, how to recover from needs_info, and what domains are out of scope. Return values are delegated to the output schema, which is appropriate.

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 all four parameters (entity, message, conversation_id, idempotency_key) are already documented, making 3 the baseline. The description still adds meaning beyond the schema by constraining re-calls after needs_info to a single consolidated message and by framing the whole call as one request, which affects how message and conversation_id get composed.

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?

Opens with a specific verb and resource ("Run Genaya AI on one request") and enumerates the change surface (task, client, lead, appointment, estimate/invoice draft, expense, reschedule/cancel/complete, text/email). The phrase "same input rules as ask_genaya" implicitly positions it against the sibling, so an agent can separate mutation from query without opening either schema.

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?

Fully routes the agent: confirm_channel=in_chat means elicitation or confirm_action with body_hash, genaya_page means surface confirm_url and stop, status=needs_info means gather and re-call in one message. It also states explicit exclusions (money, billing, roles, phone numbers, automations, image/video) that tell the agent when not to call this at all.

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.

Resources