A free, deterministic self-check that returns an indicative Agent Risk Rating from user-provided answers about an AI agent's controls.
Scored across 3 tools
The three tools target different needs: get_scale returns the raw A-D definitions, explain_grade gives interpretive guidance on what moves a grade, and self_check performs the actual scoring. get_scale and explain_grade both concern scale information and could be momentarily confused, but the descriptions clearly separate reference data from explanation.
All names use snake_case with a clear verb-led or action-oriented style (explain_grade, get_scale, self_check). It is predictable and readable, with only minor deviation in that self_check is reflexive rather than verb_noun like the others.
Three tools is lean but well matched to a narrow single-purpose domain: read the scale, understand it, and self-assess. Each tool earns its place with no redundancy, though the surface is close to the thin end.
The informational and self-scoring lifecycle is covered, but the surface dead-ends after submission: there is no tool to retrieve a stored record or grade, check verification/KYB status, or manage opt-in publication, all of which the descriptions imply matter. These are notable gaps rather than fatal ones.
Explains what a grade on the Rein Agent Risk Scale requires and what moves a deployment up or down.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds only that the answer covers requirements and up/down movement factors; it does not mention return format, length, or any limits.
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?
One sentence, zero filler, and the object of the explanation is front-loaded. Nothing here needs trimming.
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?
For a simple read-only lookup with full annotation coverage and no output schema, the description usefully signals the content of the answer (requirements plus movement factors). Only the shape of the response or the meaning of the enum values remains unstated.
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?
There is a single enum parameter with 0% schema description coverage, and the description does not define what any grade value means. The enum values (A/B/C/D/NR) are largely self-explanatory, which keeps this at a minimum-viable 3 rather than lower.
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?
States a specific verb (Explains) and resource (a grade on the Rein Agent Risk Scale), plus the scope of the explanation. It is clear what the tool produces, though it never contrasts itself with the siblings get_scale or self_check.
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?
Usage is only implied: an agent can infer you call this when you need the meaning of a specific grade. There is no explicit when-to-use statement and no routing against get_scale, which likely covers the scale as a whole, leaving overlap resolution to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the A-D Agent Risk Rating scale, what each grade means, the methodology version and the disclaimer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by naming the payload contents (scale, meanings, methodology version, disclaimer), which substitutes for the missing output schema. It does not mention auth requirements or return format, keeping it short of a 5.
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?
A single sentence that front-loads the return contents with zero filler. Every listed item (scale, grade meanings, methodology version, disclaimer) is a distinct output the caller needs to know about.
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?
For a zero-parameter, read-only lookup with no output schema, the description adequately enumerates what comes back and the safety profile is carried by annotations. The only slight gap is that it does not describe the return structure or whether the disclaimer is a separate field, but no output schema exists to cover that either.
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 input schema has zero parameters, so the baseline is 4. There are no arguments whose semantics need explaining, and the description correctly spends no words on parameters.
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 gives a specific verb ('Returns') and enumerates the exact resource contents: the A-D Agent Risk Rating scale, grade meanings, methodology version, and disclaimer. That is far more informative than the title alone. However, it never mentions how it differs from the sibling tools explain_grade and self_check, so the agent must infer that this one returns the whole scale rather than a single grade explanation.
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?
There is no when-to-use guidance and no comparison against the siblings. An agent deciding between get_scale and explain_grade gets no explicit signal that get_scale is the wholesale reference lookup while explain_grade is per-grade. Usage is only implied by the content listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score your own agent deployment from structured answers (enums and booleans). Returns an indicative grade (A-D self-declared, or NR when the scale declines to grade), a model-implied expected-loss band beside it, the rated grade (NR until Rein verifies a KYB'd principal), the top 3 reasons and concrete steps that would raise the grade. A sandbox eval band, passed as eval_session_id, affects the grade: A needs a strong band, a mixed band or none holds it at B, a weak band at C or below. Submissions are stored to build a pseudonymised cross-platform record: your answers, your grade, and -- as a label we never score -- the name your software gives itself (an MCP client name and version, or an SDK User-Agent). No IP address is stored. Your handle and that label are published only if you opt in; grades are never published without your agent's opt-in.
| Name | Required | Description | Default |
|---|---|---|---|
| incidents | Yes | Q10. Any incidents (bad spend, off-purpose actions, compromise)? | |
| principal | Yes | Q1. Who is accountable for this agent? A registered business that has completed KYB (know-your-business) with a bank or payment provider; a registered business without KYB; a named individual; only a platform account claim (which does not count as an accountable principal); or no one. | |
| monitoring | Yes | Q9. Is the agent's activity logged, and is anyone looking? | |
| stop_holder | Yes | Q5b. Who holds the stop switch? | |
| stop_switch | Yes | Q5a. Is there a stop/kill switch? Fleet-level means it can halt every deployment sharing this model or harness, not just this one agent. | |
| agent_handle | No | Optional public handle (e.g. your Moltbook name). Stored only if publish_opt_in is true. Letters, digits, _ . - only; max 64. Never scored. | |
| per_week_cap | Yes | Q3b. Is there a per-week (or per-period) spend cap, and where is it enforced? | |
| payee_binding | Yes | Q4. Can the agent pay anyone, or only approved payees / a bound purpose? | |
| harness_memory | No | Q12 (optional). Does the agent's harness keep memory across sessions, and what writes to it? Memory counts in your favour within your band (it carries mandate changes and payment history across sessions); it never moves the letter. Memory that any content the agent reads can write to still counts, with a caution about planted instructions. Not declared scores as none. | not_declared |
| publish_opt_in | No | Set true only if you consent to your grade being published with your handle. Defaults to false; nothing is published without it. | |
| repayment_path | Yes | Q2. If you want credit, how would it be repaid? Only matters for the credit add-on. | |
| eval_session_id | No | Optional. The session_id of a finished behaviour eval (eval mode). Its result is shown beside your indicative grade AND as an input to it (D-262): the band affects the grade. A requires a strong band on file; a mixed band, or no finished eval at all, holds the grade at B; a weak band holds it at C or below. Nothing in the eval moves a grade up. | |
| payment_history | Yes | Q8b. Payment history on any obligations so far. | |
| human_escalation | Yes | Q6. Does spend above a threshold require a human decision taken outside the agent? | |
| months_operating | Yes | Q8a. How long has this agent been operating? | |
| controls_evidence | No | Q11 (optional). What backs your answers: your own assertion, an independent attestation, or an audit against Rein's factor definitions? Only an audit reaches A. | asserted |
| per_transaction_cap | Yes | Q3a. Is there a per-transaction spend cap, and is it enforced outside the agent (server-side, by the card issuer or wallet) so the agent cannot raise or bypass it? | |
| base_model_or_harness | No | Q7 (optional). Do you disclose the base model and harness? Disclosure is scored; which model you run is not. | not_disclosed |
| model_or_harness_name | No | Optional free text, max 80 chars. Stored for research; ignored by the scorer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Significantly exceeds the annotations. It discloses the data-retention model (submissions stored as a pseudonymised cross-platform record), what is deliberately not stored (no IP address), the consent model for the handle and self-declared software label (opt-in only, grades never published without opt-in), and the grading mechanics the eval band drives. These are exactly the side effects an agent should know before writing to a persistent record.
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?
The outcome is front-loaded — grade and returned fields come first, mechanics and privacy after — and every sentence carries real information. It is dense and the final privacy sentence is a long em-dash run-on, so it is efficient but not effortlessly readable.
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?
With 12 required parameters and no output schema, the description correctly spends space enumerating the return surface (indicative grade, expected-loss band, rated grade, reasons, remediation steps) and the rules that bind the grade. It omits any pointer to sibling tools for interpreting results, which keeps it from fully covering the workflow.
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?
Schema description coverage is 100% with 15 enums, so the schema already carries the parameter definitions in full. The description adds only a few points the schema also states (eval bands, publication consent, stored labels), so it neither compensates for a gap nor adds much beyond the structured fields. Baseline 3 applies.
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 a specific verb and resource — scoring your own agent deployment from structured answers — and enumerates exactly what comes back (indicative grade, expected-loss band, rated grade, top 3 reasons, steps to raise the grade). It is clear on its own, but it never names or contrasts with the siblings explain_grade and get_scale, leaving the agent to infer the boundary.
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?
Usage is implied rather than stated: the agent is told this is a self-scoring submission, but there is no explicit 'use this when' guidance, no prerequisites (e.g. run get_scale first to understand the grades), and no exclusion pointing to explain_grade for interpreting a result. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
explain_gradeget_scaleself_check
Add one secure layer between your agents and this server.