Regulane compliance check

Get a Regulane compliance scorecard

report_compliance_check

Read-only

Turns the check you ran against the rules from get_compliance_rules into a scorecard: findings by severity, the ISO 27001 controls and DPDP Act sections affected, and the fix for each. Report a clean check too. Regulane does not store it. Send no source code, secrets or personal data.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repository": "<repository>",
      "scope": "<scope>",
      "rules_checked": "<rules_checked>",
      "findings": "<findings>"
    },
    "name": "report_compliance_check"
  }
}

Input Schema

Name	Required	Description
`agent`	No	Which coding agent you are, such as "Claude Code", "Cursor", "GitHub Copilot", "Codex".
`scope`	Yes	One line on what was examined, such as "staged changes, 6 files" or "src/payments".
`branch`	No	Current branch, if known.
`commit`	No	Commit SHA the check ran against, if known.
`findings`	Yes	One entry per problem found. Empty when the check is clean.
`repository`	Yes	The git remote URL, or the project folder name when there is no remote.
`rules_checked`	Yes	Every rule id you checked, including those with no finding.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: it says Regulane does not store the check, explicitly instructs the agent to send no source code, secrets or personal data, and describes what the scorecard contains. These are real operational constraints that an agent needs before invoking the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly written sentences, front-loaded with the core action and followed by the specific data-handling constraint. Every sentence carries useful information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must explain what the tool produces; it does so reasonably well (findings by severity, affected controls and sections, fixes). It remains slightly ambiguous about whether the scorecard is returned to the agent or only sent to Regulane, and what a clean-check response looks like.

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 description coverage is 100%, so the schema already documents all parameters, including the findings array and each field. The description does not add parameter-level detail beyond what the schema provides; baseline 3 is appropriate.

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: turns a compliance check into a scorecard, and names the concrete outputs (findings by severity, ISO 27001 controls, DPDP sections, fixes). It also references the sibling get_compliance_rules as the source of the rules, making the division of labour clear without opening either schema.

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?

Describes the workflow: run the check against rules from get_compliance_rules, then report it here. It also explicitly says to report clean checks, which is useful guidance. It does not spell out when not to use it, but with a single prerequisite sibling the context is clear enough.

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

All Regulane compliance check 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.