Payram

Plan a PayRam install (step by step)

payram_setup_plan

Read-onlyIdempotent

Start here to install PayRam on a VPS. Returns an ordered, personalised plan — prepare server → install → claim admin + set public URL → wallets (incl. Smart Bridge review) → API key + first payment link → hardening → store/app integration — with who runs each step (agent shell vs human/dashboard), exact commands, what success looks like, and hard stops that need the human (cold wallet, mainnet spend, root-only settings). Ask the user first whether you can run commands on their server (access "ssh") or only chat with them (access "human_runs_commands": they run each command and paste the output back). Pass stage to resume mid-way; payram_doctor tells you the stage of a running server.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ssl`	No	letsencrypt (needs domain), own_certificate, proxy (Cloudflare/your own reverse proxy terminates TLS), none. Default: letsencrypt with a domain, none without.
`path`	No	agent = headless CLI after a one-time interactive install; human = installer + web dashboard	agent
`role`	No	merchant: Take payments for your own business (default). operator: Run PayRam as a platform for other merchants and earn a fee on their volume. Must be chosen before the first project; the role locks once role-specific data exists.	merchant
`stage`	No	Where you are now; the plan starts from the next step	fresh
`access`	No	ssh = you can run commands on the server yourself. human_runs_commands = you only chat: the human runs each command and pastes the output back. Ask the user which applies before planning.	ssh
`domain`	No	Public hostname for the gateway, e.g. pay.example.com. Omit if you only have an IP for now.
`wallet`	No	First deposit wallet: usdc_base (smart-contract wallet on Base, needs a little gas), btc (xpub, no gas), or both	usdc_base
`network`	No	testnet = free test coins (recommended first); mainnet = real money	testnet
`integration`	No	What will take payments once the gateway is up	none

Output Schema

TableJSON Schema

Name	Required	Description	Default
`inputs`	Yes
`phases`	Yes
`summary`	Yes
`warnings`	Yes
`nextTools`	Yes
`humanDecisions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 11, 2026

addedInput schema / properties / access

Added value: +{
+  "default": "ssh",
+  "description": "ssh = you can run commands on the server yourself. human_runs_commands = you only chat: the human runs each command and pastes the output back. Ask the user which applies before planning.",
+  "enum": [
+    "ssh",
+    "human_runs_commands"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / phases / items / properties / steps / items / properties / executor / enum

Previous value: -[
-  "agent_shell",
-  "agent_http",
-  "human",
-  "human_dashboard"
-]New value: +[
+  "agent_shell",
+  "agent_http",
+  "human_shell",
+  "human",
+  "human_dashboard"
+]

addedOutput schema / properties / phases / items / properties / steps / items / properties / ifItFails

Added value: +{
+  "description": "What to do when the step does not give the expected result",
+  "type": "string"
+}

AddedOct 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare this a safe, idempotent, non-destructive read, so the bar is met; the description goes well beyond by disclosing the plan's structure, the human/agent division of labor, and concrete 'hard stops' (cold wallet, mainnet spend, root-only settings) that require human intervention. That is meaningful operational context an agent cannot get from the annotations alone.

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?

Front-loads the entry-point claim and the stage chain before the operational caveats. It is dense and largely waste-free, but the long em-dash-chained sentence packs multiple distinct concerns (plan contents, access modes, stage resumption, doctor cross-reference) into one breath, which slightly hurts scannability.

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?

For a 9-parameter, enum-heavy planning tool with an output schema, this covers everything an agent needs: when to invoke it, how to resolve the access ambiguity with the user, how to resume via stage, and what the plan will contain. With the output schema handling return values, nothing material is missing.

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

Parameters3/5

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

Schema coverage is 100% with 9 documented, mostly-enumerated parameters, so the schema carries the semantics. The description adds only marginal value, chiefly reinforcing 'stage' as a resume mechanism and stressing that 'access' must be confirmed with the user before planning. Baseline 3 is appropriate given the schema does the heavy lifting.

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?

States a specific verb and resource ('plan'/'install PayRam on a VPS') and enumerates the exact output shape (ordered stages, who runs each step, commands, success criteria, hard stops). It also differentiates itself from siblings by naming payram_doctor as the tool that detects a running server's stage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Start here to install PayRam on a VPS' is an explicit entry-point cue, and it names payram_doctor as the alternative for detecting an existing server's stage. It also instructs the agent to ask the user about access mode before planning. It does not, however, distinguish itself from near siblings like generate_setup_checklist, onboard_agent_setup, or get_agent_setup_flow.

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

All Payram tools Inspect

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

Need Help?