Rithmo

Get my setup

get_my_setup

Read-onlyIdempotent

Returns the setup your organization's admin gave this agent: its instructions, the documents it may rely on (each with the relied_on identity to declare to check_premises), the tools it may use, and actions: approval rules -- actions that also need a person's approval, with the exact intended_action to pass. before_every_action: check EVERY action with Rithmo before taking it, listed or not; actions never narrows that. Call it at the start of each run and work only from what it returns. Each agent also carries its config_revision — pass it to update_agent as expected_revision to edit its purpose WITHOUT starting a run — and can_update (whether this connection is permitted to edit at all). If your connection serves several agents, pass the agent_key from list_my_agents to select one; omit it to get them all. report_instructions.required: Rithmo knows your instructions only from what you report, so call declare_my_setup with them, complete, now, before your other work; Rithmo holds the actions it checks until it has them. live: false: a person has not put the agent live in Rithmo yet; do what until_live says and nothing else. blocked: true: a person must review your instructions first; do what until_unblocked says and nothing else. Read-only — this call never starts a run.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_my_setup"
  }
}

Input Schema

Name	Required	Description	Default
`agent_key`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Beyond the readOnly/idempotent annotations it discloses real gating behavior: it never starts a run, `live: false` and `blocked: true` require deferring to `until_live`/`until_unblocked`, and Rithmo withholds checked actions until instructions are declared. Dense but genuinely additive; what the returned objects look like is described only by key names.

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-loaded with the return payload before the behavioral rules, and each clause carries operational meaning. It is tightly packed with backticked flags and sub-instructions, though, reading more like a contract than a description and requiring careful parsing by the agent.

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?

A high-stakes orchestration tool with no output schema, and the description still explains the return contract, the preconditions that must be honored before acting, and the escalation path for edits. An agent has enough to call it and act correctly on the result.

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

Parameters5/5

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

The single parameter has 0% schema description coverage, and the description compensates fully: it names the source of `agent_key` (list_my_agents), the selection behavior (pick one agent), and the omission semantics (return them all). Nothing about the parameter is left to inference.

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?

Names a concrete verb and resource and enumerates the returned contents (instructions, documents with `relied_on`, tools, `actions`, `config_revision`, `can_update`), which lets an agent separate it from siblings like list_my_agents, get_hold_status, or whoami without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('Call it at the start of each run and work only from what it returns'), a conditional branch for multi-agent connections (pass `agent_key` from list_my_agents, omit to get all), and routes follow-up work to declare_my_setup, check_premises, and update_agent.

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

All Rithmo 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?