RPCS-1 Agent Tuner & Translation Bridge

io.github.travisbergen2Published by GitHub account travisbergen2v0.3.0Updated Nov 2, 2026

Find your AI agent's likely failure mode, get runtime settings, and clarify ambiguous prompts.

VerifiedStreamable HTTPWeb executableProductivity & WorkflowAI & ML

Overview

AI-generated overview

Remote, anonymous MCP server that diagnoses AI agent failure modes, recommends runtime settings, and clarifies ambiguous prompts and replies.

What you can do
  • Diagnose an agent and get a five-primitive profile, runtime settings, predicted regime and a next test
  • Detect ambiguity in a message, surface competing readings and get clarifying questions
  • Clean up fragmented text and get style-specific rewrite instructions
  • Build a communication-preference profile from five forced-choice answers
  • Recover intended meaning before acting and render a draft reply for that profile
  • Route between competing interpretations and decide whether to commit, present options or clarify
When to use it
Useful when tuning a deployed agent's temperature, top_p and strategy for a given environment, or when prompts and replies need disambiguation and tone adjustment. It suits support, coding and research agents where settings are currently guessed.
Requirements
Nothing to install: it is a public remote endpoint over streamable HTTP with no declared authentication, API keys or environment variables. The README notes per-IP throttling (default 120 requests per hour) and optional OAuth for some clients.
Before you install
Text you send, including user messages and draft replies, goes to a third-party hosted service; avoid pasting sensitive content. The profile is described as a communication-preference measure, not a psychological assessment. Recommendations are advisory settings to test, not guarantees.

Installation

In SourceWeft

  1. Open RPCS-1 Agent Tuner & Translation Bridge in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.travisbergen2%2Frpcs1-agent-tuner/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "rpcs-1-agent-tuner-translation-bridge": {
      "type": "http",
      "url": "https://rpcs1.dev/mcp"
    }
  }
}

README

RPCS-1 SDK — AI Agent Tuner

Start with the free tuner: find your AI agent’s likely failure mode, get runtime settings to try, and validate them with a harder case.

RPCS-1 helps teams make agent settings deliberate rather than guessed. Describe the task, change rate, predictability, stakes, relevant context horizon, and commitment style; it returns a five-primitive profile, a runtime recommendation, and a next test. The suite also includes SendRight for catching ambiguous prompts before handoff and the Translation Bridge for profile-aware communication rendering.

Repository Structure

rpcs1-sdk/├── packages/core/          # TypeScript engine (@rpcs1/core): tuner + translation layer + receiver-profile intake├── packages/web/           # Next.js app serving rpcs1.dev (tuner, translator, docs, Stripe, /mcp endpoint)├── packages/mcp-server/    # Standalone STDIO MCP server (what Glama and MCP clients build)├── sdk/python/             # Python SDK (pip install rpcs1)├── skills/                 # Canonical agent skill package (HF-HATP v2.0 SKILL.md)├── docs/                   # Architecture, deployment, launch playbook└── .github/workflows/      # CI/CD

Quick Start — Python SDK

bash
pip install rpcs1
python
from rpcs1 import recommend_params
config = recommend_params(    task_description="Customer support agent",    environment_entropy="dynamic",    environment_predictability="somewhat_predictable",    stakes="high",    target_platform="anthropic",)
print(config.platform_parameters.temperature)   # e.g. 0.52print(config.predicted_regime)                  # 'stable'print(config.reasoning)                         # cites Matching Principle

Quick Start — TypeScript Core

typescript
import { recommend } from '@rpcs1/core';
const rec = recommend({  task: { task_summary: 'Customer support agent' },  environment: {    entropy: 'dynamic',    predictability: 'somewhat_predictable',    stakes: 'high',    context_relevance: 'medium',    commitment_style: 'cautious',  },  target_platform: 'anthropic',});
console.log(rec.platform_parameters.temperature);console.log(rec.predicted_regime);

Development

bash
# Install dependenciesnpm ci --include=optional
# Build and test TypeScript corenpm run build --workspace=@rpcs1/corenpm run test --workspace=@rpcs1/core
# Test Python SDKcd sdk/pythonpip install -e ".[dev]"pytest -v

Web environment variables are documented in packages/web/.env.example (Stripe, Resend, license signing, rate limits). MCP production controls are listed under Production controls below.

The web app deploys to Vercel on Node 24 (region iad1); pushes to main trigger the production deployment.

The Matching Principle

The SDK implements Pred-09-5 from IMM Paper 9:

Stable receivers in an environment with entropy H satisfy TI ~ 1/H.

High-entropy environments → short attention windows (TI ~ 10). Low-entropy environments → long attention windows (TI ~ 90).

Every parameter recommendation traces back to this principle or the basin stability geometry (oscillation/overload/freeze boundary conditions).

Web App

The site can also explain the same product facts in technical, executive, plain-language, or literal-and-precise registers. The explanation changes; pricing, deliverables, and limitations do not.

Brand — Explicit Formula (product) / RPCS-1 (mechanism)

The site fronts one consumer product: Explicit Formula — the box on the landing page. Explicit: says exactly what it means (the product's one job); formula: a repeatable method. The wordmark is an advisory-sticker homage (components/StickerLogo.tsx), deliberately distinct from the trademarked RIAA label.

The mechanism brand — RPCS-1, the receiver engine, its laws, and its scorecard — is unchanged and renders as "Powered by RPCS-1" in the footer. House rule: outcome on the wrapper, mechanism one click deep.

  • The brand is a token: packages/web/lib/brand.ts. Renaming the product is one env var (NEXT_PUBLIC_BRAND_NAME) or one line — no other code changes.
  • Every station that used to compete for the nav (SendRight, Bridge, Translator, Calibrate, Tuner, R&D, …) stays live at its original route and is indexed at /labs (packages/web/lib/labs.ts).
  • The consumer domain follows the deployment: set NEXT_PUBLIC_APP_URL when it goes live. rpcs1.dev remains the mechanism home either way.

SendRight (Interpretation Mirror + Hand-off)

SendRight is the type-and-send front door: type a prompt the way you'd say it out loud, see the readings it actually supports, lock in the one you meant, and hand it to your own model app with one click.

Modules (packages/core):

  • mirror(text) — deterministic fork detectors (no ML, no API calls). Returns { clean, readings[], ambiguousSpans[] }. Detectors: compare-or-choose ("X or Y?" questions without an explicit verb), grouping forks ("A and B or C"), scope forks ("only ... and ..."), dangling pronouns, bare objects ("fix it"), external references ("the above"). Contract: silent on clean prompts — zero-fork controls in tests/mirror.test.ts enforce it. Pure function, callable from any front end (web box, NL2Build, CLI).
  • applyReading(text, clarifier) — appends the chosen reading's clarifier so the locked interpretation travels with the prompt.
  • buildHandoff(vendor, prompt) / listVendors() — per-vendor capability table for opening the user's own model app with the prompt pre-filled. Prefill URL parameters are undocumented vendor behavior and churn without notice; each entry carries a verified date and must be re-checked at release. Verified 2026-07-25: ChatGPT, Claude, Perplexity, Grok support URL prefill; Gemini and Copilot are clipboard-fallback only. Logged-out users may lose the prefill at login. All vendors degrade gracefully to clipboard.

Web: /send (packages/web/app/send) renders the box via components/SendBox.tsx — mirror runs client-side (debounced, zero network); the hand-off happens in the user's own app. SendRight never makes the model call and never sees the answer.

Feasibility boundary (honest scope): reasoning-stream digests and mid-generation stop/realign are only possible where rpcs1 itself owns the API call (the fan-out / power-user mode, not yet shipped). They are structurally impossible in vendor chat UIs and via the MCP surface — SendRight's hand-off path intentionally trades those away for zero keys, zero cost, and zero data custody.

MCP Server

RPCS-1 is also available as a public, anonymous, read-only MCP server:

text
https://rpcs1.dev/mcp

It exposes eight read-only tools across four families:

  • recommend_agent_configuration — diagnose an AI agent against environmental entropy, predictability, stakes, context horizon, and commitment style; receive runtime settings to try and a next test.
  • interpret, normalize, and rewrite — detect ambiguity, turn fragmented text into coherent prose, and return style-specific rewrite instructions.
  • route_intent — entropy routing over competing interpretations of a message: the calling model proposes candidate readings (paraphrases and priors); the deterministic router computes the posterior and decides commit, present options, or clarify. The commit-vs-clarify authority in the pipeline.
  • calibrate_profile, prepare_prompt, and render_reply — create a continuous communication-preference profile, recover intended meaning before an action, and render a reply for that profile.

Translation Layer

"Say what you mean. Hear what they meant."

The Translation Bridge treats the profile as a transportable parameter, not a category label. The five-question Calibrate flow measures communication preferences for rendering only; it is not a psychological assessment or diagnosis. prepare_prompt / render_reply use that profile on the inbound and outbound sides of an interaction. The canonical agent-facing specification lives at skills/rpcs1-translation-layer/SKILL.md.

Tuner examples

The first useful call is a support copilot under live pressure:

text
Use recommend_agent_configuration to diagnose my support copilot.
Task: refund and billing dispute triageEnvironment: dynamic, somewhat_predictable, high stakesContext relevance: mediumCommitment style: cautiousTarget platform: anthropic

The output should lead with the five-primitive profile, failure-risk score, predicted regime, runtime posture, and next test to run.

The second useful call is a coding agent in a changing repository:

text
Use recommend_agent_configuration to diagnose my coding agent.
Task: inspect a changing repository, edit files, run tests, and open a pull requestEnvironment: moderate, somewhat_predictable, medium stakesContext relevance: longCommitment style: balancedTarget platform: openai

The output should still lead with the five-primitive profile, failure-risk score, predicted regime, runtime posture, and next test to run.

Connection details and client compatibility notes are available at https://rpcs1.dev/docs/mcp. Practical coding, support, and research examples are available at https://rpcs1.dev/docs/examples.

Hyperagent uses the fixed public OAuth client hyperagent-rpcs1 with PKCE and the registered callback https://hyperagent.com/api/mcp-servers/callback. No client secret is required.

The MCP surface exposes the deterministic agent-tuning workflow alongside read-only translation and per-user rendering tools. New tools should be added only after their scoring or behavior contracts are implemented and tested in the core package.

Discovery metadata:

Production controls:

  • MCP_HOURLY_LIMIT controls per-instance MCP throttling (default: 120 requests per IP/hour).
  • MCP_MAX_BODY_BYTES limits request bodies (default: 65536 bytes).
  • MCP_ALLOWED_HOSTS is a comma-separated production host allowlist.
  • MCP_ALLOWED_ORIGINS is an optional comma-separated browser-origin allowlist. Leave it blank to reject cross-origin browser requests.
  • MCP_OAUTH_JWT_SECRET signs short-lived OAuth authorization codes and access tokens.
  • /api/health reports deployment and MCP readiness metadata.

For globally consistent abuse protection across Vercel instances, configure a Vercel Firewall rate-limit rule for /mcp. The in-process limiter is defense in depth, not a distributed quota.

Glama Docker checks should build and launch the local STDIO server, not connect to the hosted https://rpcs1.dev/mcp endpoint. Use this build spec:

json
{  "buildSteps": [    "npm ci --include=optional",    "npm run build --workspace=@rpcs1/core",    "npm run build --workspace=@rpcs1/mcp-server"  ],  "cmdArguments": [    "mcp-proxy",    "--",    "node",    "packages/mcp-server/dist/index.js"  ],  "environmentVariablesJsonSchema": {    "type": "object",    "properties": {},    "required": []  },  "placeholderArguments": {}}

License

MIT

Source: README.md at commit 4af6781

Tools

9

recommend_agent_configuration

Recommend AI agent configuration

Diagnose why a deployed AI agent may fail. Takes environmental entropy, predictability, stakes, context horizon, and commitment style, then returns receiver profile values (TI, SG, FT, UE, AR), platform parameters (temperature, top_p, strategy), regime prediction, reasoning, and warnings. Optionally pass target_model (the actual model id) to attach MEASURED per-model receiver posture (E-LIT table): evidence-graded literalness, truth-override boundary, and translation directives. Deterministic, stateless, read-only — does not store past recommendations.

Parameterstaskenvironmenttarget_modeltarget_platform

interpret

Interpret ambiguous human input

Detect ambiguity in user messages using the RPCS-1 Signature Ambiguity Framework. Returns AR level (AR0-AR5), confidence, candidate interpretations with scores, clarifying questions, and suggested next step. Use when a user says something vague, passive-aggressive, or underspecified.

Parametersrisktextrequired

fork

Fork view — how could this message read?

The calibrated ambiguity surface: deterministic structural fork detectors (reference, scope, grouping, compare-vs-choose, polysemy) with character-offset spans, plus per-reading one-line clarifiers the sender can append to lock a reading in. Returns competing readings, an ask-back question, and a forked-answer scaffold. Silent on clean text by contract. Runs the deterministic mirror floor only over MCP (no model). Prefer this over interpret for span-level ambiguity detection: interpret’s entity list is a word-list engine (calibrated 2026-08-15: no discrimination on conversational text) — advisory only.

Parameterstextrequiredrejected

normalize

Normalize fragmented human input

Clean up text with ellipses, fragments, and run-on thoughts into coherent prose. Use when a user types stream-of-consciousness or fragmented input.

Parameterstextrequired

rewrite

Rewrite text for a target audience

Get rewrite instructions for adapting text to a specific style: technical, plain, socially_gentle, concise, detailed, or direct. Use when communication needs tone adjustment.

Parameterstextrequiredstyle

calibrate_profile

Calibrate a user’s receiver profile

Build a ReceiverProfile (TI, SG, FT, UE, AR — continuous 0-100, never a category label) from five behavioral forced-choice answers. Call with NO answers to get the five questions to ask the user; call again with their answers (a/b/c per primitive) to get the profile. Store the returned profile JSON in the user’s notes or memory and pass it to render_reply / prepare_prompt on every turn. Deterministic and stateless — nothing is stored server-side. Schema: https://rpcs1.dev/v1/receiver-profile.json

Parametersanswers

prepare_prompt

Prepare a user’s message before acting on it

The inbound half of the Translation Bridge loop. Takes the user’s raw message (possibly ambiguous, fragmented, or underspecified) plus their ReceiverProfile, and returns the recovered intent, a canonical translation to act on, ambiguity level, and — profile-aware — whether to clarify or commit. Call this before acting on any ambiguous user request. Scope note: its detectors are lexical/structural (vague signals, ambiguous references) — for the commit-vs-clarify DECISION, route_intent (with your own proposed readings) is the authority; when they disagree, follow route_intent.

Parametersrisktextrequiredprofile

render_reply

Render a reply for a specific user’s receiver profile

The outbound half of the Translation Bridge loop. Takes your draft reply plus the user’s ReceiverProfile and returns deterministic rendering instructions (structure, warmth, explicitness, revision posture, ambiguity handling — each with a why-trace). Apply the instructions to your draft before answering. Call this on every reply to a calibrated user.

Parameterstextrequiredprofilerequired

route_intent

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

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).

Parameterstextrequiredprofilehypotheseslikelihoods

Version history

1
  1. v0.3.0LatestSep 16, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts