Arrumou Neural

Criar reserva

create_reservation

Destructive

Cria uma ou mais estadias (grupo) para um cliente cadastrado com tarifa base, plano, diária personalizada ou pacote fixo. Verifica disponibilidade e exige aprovação do usuário. Sinal/pagamento é lançado separadamente.

Escopo: reservations:write · Risco: consequential (prévia + aprovação do usuário obrigatória) · Efeitos: Cria Booking(s), lançamentos de diárias e registro de atividade. · INDISPONÍVEL nesta autorização (escopo não concedido ou papel sem o módulo)

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": {
      "customer_id": "<customer_id>",
      "check_in": "<check_in>",
      "check_out": "<check_out>",
      "rooms": "<rooms>"
    },
    "name": "create_reservation"
  }
}

Input Schema

Name	Required	Description	Default
`rate`	No
`notes`	No
`rooms`	Yes
`source`	No	DIRECT, AIRBNB, BOOKING, WHATSAPP, PHONE, SITE...	DIRECT
`day_use`	No
`check_in`	Yes
`discount`	No
`breakfast`	No
`check_out`	Yes
`agency_ref`	No
`approval_id`	No	Id de uma aprovação já decidida pelo usuário para esta mesma ação. Omita para receber a prévia e o link de aprovação.
`customer_id`	Yes	Cliente já cadastrado (use search_guests ou create_guest).
`idempotency_key`	No	Chave de idempotência escolhida pelo cliente; repetir a chave com os mesmos dados devolve o mesmo resultado.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Adds substantial context beyond annotations: required scope (reservations:write), risk class, concrete side effects ('Cria Booking(s), lançamentos de diárias e registro de atividade'), and the preview-then-approve flow. It also flags current unavailability due to missing scope/role, which is exactly the runtime precondition an agent needs.

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 functional sentence is front-loaded, followed by a compact metadata line (scope/risk/effects/unavailability) that reads like a structured footer. Dense but every clause carries information; minor redundancy between 'exige aprovação' and 'prévia + aprovação obrigatória'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-risk mutation with nested objects and no output schema, it covers side effects, approval gating, and entitlement status well. It leaves unclear what is returned on success (booking identifiers) and what happens when the availability check fails, which is a meaningful gap for a 13-parameter create tool.

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 only 31% across 13 parameters, and the description only clarifies the rate mode family and that payments are separate. It says nothing about source, day_use, breakfast, discount rules, or the rooms/occupancy structure, so it only partially compensates for the coverage gap.

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?

Starts with a specific verb+resource ('Cria uma ou mais estadias (grupo) para um cliente cadastrado') and enumerates the rate modes it supports (tarifa base, plano, diária personalizada, pacote fixo). It also distinguishes itself from the payment siblings by stating 'Sinal/pagamento é lançado separadamente', so an agent can separate this from add_reservation_payment without reading 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the approval workflow ('exige aprovação do usuário', 'prévia + aprovação do usuário obrigatória') and that payment is handled by another tool, which is real routing guidance. It does not contrast with quote_stay or block_dates, so the when-not side is incomplete.

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

All Arrumou Neural tools Inspect

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.