RPCS-1 Agent Tuner & Translation Bridge

Measured conclusion: Deep-tested. L2 outcome: tools_ok.

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

Add to your agent

Copy this into your MCP client config:

{
  "mcpServers": {
    "RPCS-1 Agent Tuner & Translation Bridge": {
      "url": "https://rpcs1.dev/mcp",
      "transport": "streamable-http"
    }
  }
}

Measured tools (9)

• recommend_agent_configuration read-only

  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.

  Parameters:

  • task — object
  • environment — object
  • target_model — string — Optional: the actual model id this agent will run on (e.g. "claude-sonnet-4-6", "deepseek-v4-pro"). When it matches a measured per-model receiver entry (E-LIT table), measured translation directives and evidence-graded posture data are attached to platform_parameters. Unknown models fall back to platform-level behavior unchanged.
  • target_platform — string — The platform whose runtime parameters should be recommended.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• interpret read-only

  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.

  Parameters:

  • text (required) — string — The message to interpret.
  • risk — string — Risk category for ambiguity threshold.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• fork read-only

  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.

  Parameters:

  • text (required) — string — The message to analyze for forks.
  • rejected — array — Reading summaries the user already rejected — never re-offered.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• normalize read-only

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

  Parameters:

  • text (required) — string — Fragmented text to normalize.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• rewrite read-only

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

  Parameters:

  • text (required) — string — Text to rewrite.
  • style — string — Target audience style.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• calibrate_profile read-only

  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

  Parameters:

  • answers — object — Chosen option id per primitive. Omit entirely to receive the questions.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• prepare_prompt read-only

  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.

  Parameters:

  • text (required) — string — The user’s raw message.
  • risk — string — Risk category for the ambiguity threshold.
  • profile — object — The user’s ReceiverProfile from calibrate_profile. Shapes clarify-vs-commit behavior.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• render_reply read-only

  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.

  Parameters:

  • text (required) — string — Your draft reply.
  • profile (required) — object — The user’s ReceiverProfile from calibrate_profile.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• route_intent read-only

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

  Parameters:

  • text (required) — string — The user’s raw message.
  • profile — object — The user’s ReceiverProfile from calibrate_profile. Shapes commit-vs-clarify thresholds.
  • hypotheses — array — Candidate interpretations. Omit to use a generic six-intent starter set plus a catch-all.
  • likelihoods — object — Optional externally computed likelihood per hypothesis id (e.g. model-derived) — replaces the lexical scorer.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

Publisher website Repository

Measured by MCPYP probing. Untested fields are omitted, never estimated. Listing is always free; MCPYP never proxies calls or stores user tokens.