Skip to main content
Glama
Sign In

Red by Big Red Cloud

by io.github.BigRedCloud
OverviewDiscussionsAdmin

Route Request

brc_route_request
Read-only

Routes a single user request to a RED workflow and uses its text for request classification and authorization provenance. Handles requests such as ‘how do I add a customer,’ ‘create a sales invoice,’ ‘read,’ ‘update,’ ‘delete,’ ‘correct,’ ‘undo,’ and ‘reverse.’ When host-signed original-request metadata is available, the text is checked against it before a route token is issued. Only the request being routed is needed; conversation history and prior turns are not required.

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": "brc_route_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
messageYesThe single user request being routed, such as 'add a customer'; not conversation history or prior turns. When host-signed original-request metadata is available, this text is checked against it and used to bind any route token to the request.
companyNameNoOptional selected company; binds the issued routeToken to that exact company. Legacy calls without it bind on first transactional use.
connectionRefNoOpaque Red connection reference returned by brc_confirm_company_connection. Pass this exact value on every later tool call when the MCP client rotates session ids (for example Vibe/Mistral). Keep reusing the same connectionRef after successful tool calls — do not start a new connection because a lookup returned empty or partial data. It is not an API key and does not contain credentials.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / message / description
      Previous value: -"The user's complete original message to classify, for example add a customer or how do I add a customer."New value: +"The single user request being routed, such as 'add a customer'; not conversation history or prior turns. When host-signed original-request metadata is available, this text is checked against it and used to bind any route token to the request."
  2. Changed1 schema field changed
    • addedInput schema / properties / companyName
      Added value: +{
+  "description": "Optional selected company; binds the issued routeToken to that exact company. Legacy calls without it bind on first transactional use.",
+  "minLength": 1,
+  "type": "string"
+}
  3. Added
  4. Removed
  5. Added

TDQS

A3.5/5.0
Behavior4/5

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

Beyond the readOnly/non-destructive annotations, the description discloses the real behavior: the text feeds classification and authorization provenance, host-signed original-request metadata is verified before a route token is issued, and the token gets bound to the request. It does not say what happens on a verification failure or a non-matching request, which is the main residual gap.

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

Conciseness3/5

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

The core routing purpose is front-loaded, but the enumeration of 'read,' 'update,' 'delete,' 'correct,' 'undo,' and 'reverse' is low-value keyword padding, and the host-signed metadata check is repeated from the schema. Trimming the list would sharpen the definition without losing meaning.

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?

With no output schema, the description should describe what comes back, but it only gestures at 'a route token is issued' without its shape or what the classification result looks like. It does correctly bound the input (single request, no history) and covers the safety profile via annotations, so it is adequate but incomplete for a dispatch 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 100%, so message, companyName, and connectionRef are already fully documented in the schema. The description only reinforces the 'single request, no conversation history' constraint and the host-signed metadata check, both of which also appear in the schema text, so it adds little beyond the baseline.

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 description uses a specific verb and resource — 'Routes a single user request to a RED workflow' — plus the secondary purpose of classification and authorization provenance, which an agent could not infer from the name alone. It does not reference any sibling, and given ~150 CRUD siblings it never clarifies that this is the entry/dispatch step rather than a CRUD operation.

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?

Usage is implied rather than stated: the tool is for classification/routing before other actions, and the description clarifies the caller should pass only the current request, not history. There is no explicit 'call this before X' or 'do not call this when Y', and no named alternative, so the agent must infer the sequencing from context.

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

All Red by Big Red Cloud 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