mcp server
RPCS-1 Agent Tuner & Translation Bridge
Find your AI agent's likely failure mode, get runtime settings, and clarify ambiguous prompts.
Description as published by the maintainer. Source
- version 0.3.0
- active
- translation
active — Registry entry last updated 2026-07-28. Dashed tags are derived by ZBS Index from the published description, not stated by the maintainer.
What this server can do
8 functions, named and described by the server itself. Parameter names are shown because they say more about what a function does than its name usually does.
calibrate_profile(answers)- 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
interpret(risk, text)- 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. Required: text.
normalize(text)- Clean up text with ellipses, fragments, and run-on thoughts into coherent prose. Use when a user types stream-of-consciousness or fragmented input. Required: text.
prepare_prompt(risk, text, profile)- 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. Required: text.
recommend_agent_configuration(task, environment, target_model, target_platform)- 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.
render_reply(text, 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. Required: text, profile.
rewrite(text, style)- Get rewrite instructions for adapting text to a specific style: technical, plain, socially_gentle, concise, detailed, or direct. Use when communication needs tone adjustment. Required: text.
route_intent(text, profile, hypotheses, likelihoods)- 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). Required: text.
Last successful function declaration observed on . Source: https://rpcs1.dev/mcp. We list what the server declared; we do not call any of these functions.
Endpoint status observed on . Source: https://rpcs1.dev/mcp.
Signals
These are separate measurements of different things. They are deliberately not combined into one score, because a popularity number that mixes website traffic with saves and stars cannot be checked or acted on.
| Signal | Value | What it measures | Window | Observed | Source |
|---|---|---|---|---|---|
| Latest published version | 0.3.0 | Latest version string the maintainer published to the registry. | as of fetch | Model Context Protocol | |
| Registry record last updated | 2026-07-28 | When the registry record was last updated by its maintainer. | point in time | Model Context Protocol | |
| First listed in the MCP Registry | 2026-07-28 | Date this server was first published to the official MCP Registry. Not a usage or quality measure. | point in time | Model Context Protocol | |
| mcp tools declared | 8 tools | Number of functions the server itself declared when asked to list them. This is what the server offers an agent, not a measure of how well any of them work. | as of probe | rpcs1.dev | |
| mcp endpoint status | ok | The server listed 8 functions when asked. | as of probe | rpcs1.dev |
Where to get it
This record as data
Every field on this page, with its source and observation date, is in the catalog JSON. Fetch the whole kind at once instead of parsing this HTML.
GET /api/v1/entries/mcp_server.json