onboard_agent_setupDeprecated: use payram_setup_plan, which does this and lets you personalise it. Returns the default headless plan (testnet, USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| markdown | Yes | ||
| description | No |
Changes observed during successful MCP inspections.
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered and the description is consistent with it. The description adds the deprecation status and the exact configuration returned, but says nothing about permissions, side effects, or how the plan is consumed. With annotations carrying the safety burden, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the deprecation notice front-loaded, followed immediately by the redirect and the return scope. No filler and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be detailed, and the description still summarizes them. For a zero-param, deprecated tool the only essential information is the redirect, which is present; the minor gap is that it never states what callers should expect the plan to contain beyond two config values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there is no parameter semantics for the description to clarify or compensate for. Schema coverage is reported at 100% with an empty properties object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is deprecated, identifies the replacement (payram_setup_plan), and specifies what it returns (the default headless plan with testnet/USDC-on-Base config). The literal action ('install PayRam as an agent') comes from the title rather than the description, but the return scope is clearly conveyed and the tool is differentiated from its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the alternative explicitly and gives the reason to prefer it ('which does this and lets you personalise it'), effectively telling the agent when not to use this tool. This is exactly the routing guidance an agent needs for a deprecated entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.