Rota Nacional

Conversar

conversar

Chat pelos modelos da Rota (rota/auto escolhe pelo conteúdo), conforme a política de privacidade da organização. Pede a chave de API. Confira franquia e preço em /api/pricing antes de usar. Use a rota protegida compatível com a política da organização. Você não precisa incluir a mesma política e cobrança de uso em cada cliente. O gateway nativo preserva o corpo do provedor e não aplica a barreira. Rota externa exige aceite. Os controles não garantem detecção de todo dado pessoal nem inferência no Brasil.

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": {
      "model": "<model>",
      "messages": "<messages>"
    },
    "name": "conversar"
  }
}

Input Schema

Name	Required	Description
`model`	Yes	Um id do catálogo (`rota/*`, em `GET /v1/models`); `rota/auto` escolhe pelo conteúdo.
`privacy`	No	Só endurece a política da organização. restore:false mantém os marcadores na resposta.
`messages`	Yes	A conversa: `role` (`system`, `user`, `assistant` ou `tool`) e `content` de cada mensagem; o conteúdo passa pela barreira.
`max_tokens`	No	O teto de tokens da resposta; conta na cota e no débito do crédito.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

B3.2/5.0

Behavior3/5

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

With readOnlyHint=false already declaring this as a non-read operation, the description does add real context: quota consumption and credit debits, API-key auth, and an explicit limitation that the controls don't guarantee detection of all personal data or in-Brazil inference. That credit is undercut by confusing fragments about a 'gateway nativo' that 'não aplica a barreira' and 'Rota externa exige aceite', which read like notes about other routes and leave the actual behavior of this call ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, but the remainder is a run-on stream of unrelated caveats, including an instruction to client authors ('Você não precisa incluir a mesma política e cobrança de uso em cada cliente') and provider-gateway remarks that don't help an agent call this tool. Substantial trimming is needed.

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

Completeness3/5

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

For a chat tool with nested `privacy` parameters and no output schema, the description covers auth, billing, and privacy limitations, which is useful. It still never sketches the response shape or how `privacy.restore` affects returned content, and the stray gateway/external-route lines add noise rather than completing the picture.

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 `model`, `messages`, `privacy`, and `max_tokens` are already documented in the schema, including the candidate privacy modes and the restore flag. The description only echoes the `rota/auto` routing hint and adds no format or constraint detail beyond what the schema states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause names a specific verb+resource combination ('Chat pelos modelos da Rota') and clarifies the `rota/auto` routing behavior, so an agent knows this is the chat-completion entry point. It does not, however, distinguish itself from nearby chat-like siblings such as `native_responses` or `enviar_ao_bot`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It gives precondition-style guidance: an API key is required, quota and price should be checked at /api/pricing first, and the protected route must match the organization's privacy policy. What it never states is when to pick this tool over the alternative chat/response tools, so selection guidance remains implicit.

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

All Rota Nacional 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.

Resources

Need Help?