01
Schema Service structure enters the workbench first
Reflection, local Proto folders, and Git Proto repositories feed one discovery path before a request is sent.
Reflection + Proto RPCORA / LOCAL-FIRST gRPC chain replay + Doctor evidence
Debug gRPC chainswithout rebuilding context
Keep service discovery, request composition, Metadata/Auth, runtime variables, and Doctor diagnosis inside one local workflow. Tokens, user IDs, and trace IDs move with the chain instead of living in copy-paste steps.
01 Reflection + Proto fallback 02 Runtime bindings 03 Redacted reports
RPCORA Request Body Composer prod
Unary 127.0.0.1:50051 Send
Service Definition Metadata Auth TLS
Request Body Composer user.v1.GetUserRequest
4 / 4 valid 707172737475
user_idstring · required
user_123456 env.USER_ID with_profilebool
true static role_filteroneof · RoleSelector
admin_only oneof trace_idstring · runtime
{{session.traceId}} chain metadatamap<string,string>
+ 3 entries map No errors Runtime values resolved 120ms · OK
macOS Windows Linux
gRPC Workbench
Turn gRPC debugging into a traceable desktop workflow.
02
Context Auth and variables move with the call
Environment variables, Auth, Metadata, TLS, and runtime bindings resolve before send time.
Runtime bindings03
Evidence Failures become usable evidence
Chain steps, gRPC status, duration, schema source, and Doctor results form a redacted debugging report.
Doctor report Workflow
From service discovery to chain replay, RPCORA keeps the context intact.
A single request is not an isolated action. RPCORA connects schema, Payload, Auth, Metadata, runtime variables, and diagnosis so each debug run can become the next replayable path.
Local workspace Unary chain replay Doctor evidence
RPCORA / run desk Reflection connected
Discover service
Connect to a target and read service, method, request, and response types.
Compose payload
Handle required fields, oneof, maps, and arrays inside the Request Body Composer.
Bind runtime values
Bind upstream responses, environment variables, and Metadata into downstream requests.
Replay chain
Run saved requests in order, find the failed step, and produce Doctor results.
01messageuser.v1.GetUserRequest
02user_idenv.USER_ID
03with_profiletrue
04trace_id{{session.traceId}}
05metadata+ 3 entries
No errors6/6 fields filled
Evidence
A report should be runnable evidence, not a screenshot.
When a call fails, RPCORA keeps resolved context, Doctor checks, and chain reports in one evidence panel. You can see where the failure happened, which context was present, and what to inspect next.
Inspect variables before sending
{{session.token}}, {{profile.user_id}}, trace IDs, and other context are visible before runtime.
Context readyTurn failures into workable clues
Target, TLS, Metadata, Reflection, Proto fallback, and gRPC status stay separated.
4 checks passedShare redacted evidence with the team
Reports keep chain steps, duration, error summary, and next actions while hiding sensitive values.
Redacted Doctor Report redacted
step03 · profile.UserService/GetUser
schemaReflection · user.v1.GetUserRequest
metadataauthorization: Bearer ******
statusOK · 120ms
For Teams
Built for people who debug services every day.
Local and internal service debugging
Run a single gRPC method, save reusable requests, and replay the context behind authenticated business calls.
Replay critical paths consistently
Fix login, query, create, and verify steps into a chain, then share a redacted failure report with engineers.
Inspect TLS, metadata, and schema problems
Quickly separate target, certificate, permission, reflection, Proto, and response-shape failures.
Why RPCORA
RPCORA is not another request panel. It keeps gRPC debugging context on one path.
RPCORA is built for real service debugging: understand schema, run the request, then keep context, replay paths, and diagnosis evidence inside the local workbench.
gRPC debugging starts with schema
RPCORA treats services, methods, message types, Metadata, TLS, and gRPC status as first-class debugging context instead of a generic URL form.
Runtime context moves between calls
Login, auth, user IDs, trace IDs, and environment variables can move across saved requests, turning a working call into a repeatable business path.
Debugging output becomes shareable evidence
Doctor and chain reports organize failed steps, schema source, runtime variables, duration, and gRPC status for backend, QA, and platform teams.
Inputhost:port + schema
ResolveMetadata · Auth · TLS
Replaytoken -> userId -> traceId
ShareDoctor report · redacted
Use RPCORA When
When gRPC debugging depends on context, chains, and evidence, RPCORA becomes the clearer path.
When debugging needs full gRPC context
Discovery, Payload, Metadata, Auth, TLS, response status, and runtime variables stay in one desktop workbench.
When one call should become a replayable chain
Save working requests as steps, then connect login, auth, query, and verification into a stable replay path.
When results need to travel to another engineer
Doctor and chain reports explain the failed step, runtime context, and practical next action with structured evidence.