Skip to main content
Glama

RPCS-1 Agent Tuner & Translation Bridge

by io.github.travisbergen2
OverviewDiscussions(1)Admin

Route an ambiguous request: commit, present options, or clarify

route_intent
Read-onlyIdempotent

Entropy routing over competing interpretations — the model proposes, the deterministic core disposes. YOU generate the candidate readings of the user’s message (3–7 short hypotheses covering the plausible interpretations, INCLUDING likely-typo readings, idiom-vs-literal readings, and domain senses) and pass them as hypotheses, ideally with your own likelihoods (0–1 per reading) AND a paraphrase per reading — the user’s message rewritten unambiguously under that interpretation, so the user can VERIFY intent by recognition before anything commits (one misread prompt skews a whole thread). The router computes the posterior and its normalized entropy T̂ and returns the decision: commit (one reading dominates), commit_with_note (close alternative disclosed), present_options (several readings live), or clarify (ask before acting — open-endedly when nothing discriminates). Thresholds adapt to the user’s ReceiverProfile (AR widens/narrows the commit region; high FT discloses near-ties). This tool is the commit-vs-clarify AUTHORITY in the pipeline. Omitting hypotheses falls back to a generic six-intent PRODUCT-ROUTING starter set — do not use the fallback for interpreting arbitrary sentences. Deterministic, stateless, read-only. Benchmarked: RTEB v1.1 (developer-bench grade; see docs/routing.md).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe user’s raw message.
profileNoThe user’s ReceiverProfile from calibrate_profile. Shapes commit-vs-clarify thresholds.
hypothesesNoCandidate interpretations. Omit to use a generic six-intent starter set plus a catch-all.
likelihoodsNoOptional externally computed likelihood per hypothesis id (e.g. model-derived) — replaces the lexical scorer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / hypotheses / items / properties / paraphrase
      Added value: +{
+  "description": "The user’s message REWRITTEN UNAMBIGUOUSLY under this reading. Strongly recommended: when the router asks, the user verifies intent by reading these restatements, not by decoding labels.",
+  "maxLength": 500,
+  "minLength": 1,
+  "type": "string"
+}
  2. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool is 'deterministic, stateless, read-only' and mentions benchmarks, providing context beyond annotations without contradiction.

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 description is somewhat long but packs essential details; every sentence earns its place. Could tighten a bit, but structure front-loads purpose and then provides specifics 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?

Despite no output schema, the description covers return decisions (commit, commit_with_note, present_options, clarify), fallback behavior, and the role of ReceiverProfile. Given tool complexity (4 params, nested objects), this is complete and actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description significantly enriches parameter meaning: explains the purpose of hypotheses (with likelihoods and paraphrases), why paraphrases matter for user verification, and how profile dimensions affect thresholds. This goes well beyond schema descriptions.

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 explicitly states the tool's role: 'Entropy routing over competing interpretations' and 'this tool is the commit-vs-clarify AUTHORITY in the pipeline.' It clearly differentiates from siblings like interpret or normalize.

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?

The description tells when to use (ambiguous requests, generating hypotheses) and when not to ('do not use the fallback for interpreting arbitrary sentences'). It also references the sibling tool calibrate_profile for profile setup.

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

All RPCS-1 Agent Tuner & Translation Bridge 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