Skip to main content
Glama
oleg-vdv

io.github.oleg-vdv/kepil

by oleg-vdv
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Kepil

PyPI License: AGPL v3

Accountability layer for AI agents. Give every agent a passport, put every action through one gate, and keep a log that cannot be rewritten afterwards.

53% of organisations have had an AI agent exceed its intended permissions. 48% of agents in production run with no monitoring at all. Only 22% treat an agent as an entity with its own identity. — Cloud Security Alliance and State of AI Agent Security, 2026

Kepil is what the other 78% are missing: identity, mandate, enforcement, evidence — and the part nobody else does, undo.

pip install kepil
python -m kepil.admin        # http://localhost:7317

Русская версия: README.ru.md

What it does

Passport. Every agent version gets an immutable card: who built it, who runs it, what it does, what it will never do, its risk class, its autonomy class, its limits, and when its risks are due for review. A new version is a new card; the old one is kept forever.

Mandate. A machine-readable power of attorney for one job: allowed actions, allowed systems, spending limits, a validity window, and which action types must be confirmed by a human. Anything not explicitly allowed is refused.

Gate. The single point through which an agent touches the outside world. Every action is checked against the mandate before a model is even called. Fail-closed: any error inside the check means refusal, never a pass.

Journal. Append-only JSONL where every record carries the hash of the one before it. Editing or deleting a record is detectable — by anyone, using an independent implementation:

npx proofbyte-agent-trace verify data/journal.jsonl

Undo. The journal is a graph of actions, and every profession declares its compensating action. Kepil walks that graph backwards and stops honestly at the first step that cannot be undone. Agent platforms record what happened; this one puts it back.

Confirmations on your phone. Irreversible actions arrive in Telegram with two buttons — approve or return — so being accountable does not mean sitting at a laptop.

Related MCP server: Dvarapala

Use it from any MCP client

Kepil ships an MCP server, so an editor, an assistant or another agent can work through it — and every action still passes the same gate into the same journal.

{
  "mcpServers": {
    "kepil": { "command": "python", "args": ["-m", "kepil.mcp"] }
  }
}

Seven tools: list professions, create an order, run a step, read order status, see what is waiting for a human, verify the journal, read an agent passport.

One tool is deliberately missing: confirmation. If a model could approve an irreversible action, the human would drop out of the chain and the whole design would be pointless. The confirmation card goes to a person — in the panel or in Telegram — and no MCP client can press it. A test enforces this.

Guard your existing automations

Kepil has a small JSON API, so an n8n workflow, a Make scenario or your own script can ask permission before acting:

curl -X POST http://localhost:7317/api/check   -H "Authorization: Bearer $KEPIL_API_TOKEN"   -H "Content-Type: application/json"   -d '{"order_id":"ord-0042","action":"send:message","system":"whatsapp.local"}'
{ "decision": "await_human", "allowed": false, "needs_human": true,
  "reason": "необратимое действие: требуется подтверждение человека" }

The answer is recorded in the journal, so later you can show on what grounds the automation did — or did not do — something. For n8n there is a ready node: n8n-nodes-kepil.

The API stays off until you set a token (panel → Settings, or KEPIL_API_TOKEN). A panel bound to localhost is protected by the binding; a programmatic interface is not, so it is disabled by default.

An agent here is never fully autonomous

AgentPassport refuses to be constructed with the autonomy class where a human can no longer cancel a decision. That is a deliberate architectural limit rather than a missing feature — see ADR-0002. The gate enforces the same rule regardless of what a profession definition claims.

Professions: behaviour as data, not code

An agent's job is a JSON description: ordered steps, boundaries, limits, irreversible action patterns, rollback rules. Adding a new kind of work means adding a file — or filling in a form in the panel. The dangerous parts stay in code and under test.

Five ship with the project: inbound leads, process automation, bookkeeping documents, AI-adoption audit, public-procurement packages.

Undo that stops honestly

An order's journal is a sequence of actions and every profession declares the compensating action for each, so the panel can walk it backwards: pick a window, and the pass runs from the last action towards earlier ones, stopping at the first one that cannot be undone. What will happen is shown before the button is pressed, naming the step where the pass will stop — an undo promise that quietly fails is worse than no undo at all. The result is recorded as an operator's decision, which is why neither the MCP server nor the JSON API can roll anything back: an agent undoing its own actions would be signing in somebody else's name.

The panel

python -m kepil.admin opens an operator console: orders, professions, agent passports, a meter (actions, tokens, cost, human time replaced), the compliance generator, the journal with chain verification and anchoring, and settings.

State is plain JSON files under KEPIL_DATA (default ./data). No database: you can open them, read them, and attach them to a dispute.

The confirmation round trip is what witnesses the log

A hash chain proves the surviving records agree with each other. It says nothing about what was removed: cut the journal at record 3, rewrite everything after it with correct prev_hash values, and verification prints Integrity confirmed over a shorter history that is perfectly consistent with itself.

The fix was already in the design without being used. The confirmation card leaves the writer process and goes to a person, in the panel or in Telegram, and that round trip is the one artifact produced outside the writer. So the card now carries the current chain head, the decision that comes back quotes the head it saw, and the journal records it.

A rewritten prefix now has to contradict a message sitting somewhere the writer cannot reach. Verification stops being a self-consistency check and becomes a second party's statement about what the log looked like at a given moment.

chain against itself:  Integrity confirmed
witnessed head:        confirmation at record 0 refers to root sha256:a3d124b9…,
                       which is no longer in the chain: the history was cut or
                       rewritten (3 such confirmations)

Records written after the last witnessed head stay unprotected. That is where the guarantee stops, and it says so.

This came from a reader, ANP2 Network, who described both the attack and the fix in one comment.

Survey: what the installation proves, and what a person must answer

A compliance survey is a list of questions bound to legal norms. Some of the answers are already in the installation — risk and autonomy class in the passport, documentation completeness in the pack, confirmations and stops in the journal. The rest a person has to answer: the provenance of training data, the feature list of a model, insurance contracts.

The panel runs a checklist and splits every item into three: closed by evidence from the installation, a gap, or needs a human. On a real installation about a fifth closes automatically. If it closed much more than that, the checklist would be incomplete.

Two properties are worth stating. A resolver returns a fact — "no high autonomy declared", "zero stops in the journal" — never a verdict of compliance; the conclusion and the signature stay with a person. And a checklist file references the name of a resolver declared in code and contains nothing executable, because otherwise a JSON file from elsewhere would be a way to run code on the machine that keeps the journal.

The integrity resolver reports the system's own weakness: if the chain root has never been fixed, or is fixed unsigned next to the journal, there is no outside witness and the whole history could be rewritten.

8.2  needs a human   anchors exist, but 1 of 1 is unsigned and stored next to
                     the journal — there is no outside witness

Compliance packs

Documentation requirements differ by country and change faster than code, so the texts live outside the engine. The neutral pack shipped here follows international practice (ISO/IEC 42001, record-keeping in the spirit of the EU AI Act). Jurisdiction packs — for example Kazakhstan's AI Law No. 230-VIII with order No. 95/НҚ — are dropped into $KEPIL_DATA/packs as files.

Design rules

  • Zero dependencies. The core runs on the Python 3.11+ standard library, and CI fails the build if a third-party import appears. That keeps Kepil installable inside an air-gapped perimeter, and keeps the supply-chain attack surface of a tool that sees every action at zero.

  • Values never enter the journal — only types, counts and hashes.

  • The verifier is a separate implementation in another language. Proof that only its own author can check is not proof.

Related projects

Project

Role

agent-trace

Independent journal verification and evidence packs (MIT)

AI-Gateway

PII and secret masking between your apps and external models

AutoGov

Discovery of shadow automations and the credentials they can reach

Status

Alpha, 170 tests. Interfaces may still change. Nothing here is a legal opinion: before relying on generated documents, have them reviewed by a lawyer in your jurisdiction.

License

AGPL-3.0-or-later. Running a network service built on Kepil obliges you to release your own source under the same terms — or to take a commercial licence. See NOTICE.md.

Available Tools

7 tools
agent_passportC

Паспорт агента: назначение, границы, классы риска и автономности.

ParametersJSON Schema
NameRequiredDescriptionDefault
agent_idYes

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool returns something about the agent's passport, but it doesn't disclose whether this is a read-only operation (likely, but not explicit), whether it requires authentication, what it returns in detail, or any side effects. The term 'паспорт' suggests a static reference, but that's not explicitly confirmed. Given no annotations and minimal information, this scores low.

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

Conciseness3/5

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

The description is a single short sentence, which is concise, but it lacks front-loading of the most critical information. It lists what the passport contains (purpose, boundaries, etc.), but it doesn't start with a clear verb phrase describing the action. The structure is acceptable, but it could be improved by leading with a verb like 'Retrieve' and then stating content. It earns a 3 for being succinct but not optimally structured.

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

Completeness2/5

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

Given the tool's complexity is low (one parameter), but with no output schema and no annotations, the description needs to explain what the agent receives from this call. It doesn't state the return format, the type of data (e.g., JSON object with risk levels), or how the content can be used. The description is too terse to be complete; an agent would need to infer the structure and content of the result, which is a significant gap.

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

Parameters2/5

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

Schema coverage is 0%, and there is only one parameter (agent_id). The description does not explain the meaning of agent_id beyond its name; it doesn't specify what format it should be in (e.g., a UUID), where to find it, or how it relates to 'agent'. Since the description doesn't compensate for the schema's lack of documentation, and given low coverage, the agent may not know how to correctly provide agent_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Паспорт агента: назначение, границы, классы риска и автономности' translates to 'Agent passport: purpose, boundaries, risk classes and autonomy levels', which clearly indicates this tool retrieves a specification of the agent's purpose, boundaries, risk classes, and autonomy. However, it does not specify the exact resource or action (e.g., whether it fetches or creates a passport), and it doesn't differentiate from siblings. It is more than a tautology but lacks explicit verb and resource clarity.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like list_professions or verify_journal. The description implies it provides information about the agent, but it doesn't state a specific use case, such as 'Use this to retrieve the current agent's risk profile before executing actions.' No exclusions or comparisons are provided.

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

create_orderC

Создать заказ на профессию: выдаётся паспорт агента и мандат на срок.

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo
client_binNo
professionYes
client_nameYes

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It adds a concrete behavioral consequence (issuing agent passport and mandate for a term), but omits other important aspects like permissions, reversibility, idempotency, or additional side effects. It provides some value but not comprehensive transparency.

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?

The description is a single, efficient sentence with no filler. It front-loads the core purpose and a key consequence, though it could be slightly more informative without losing conciseness.

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

Completeness2/5

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

For a four-parameter tool with no output schema and no annotations, this definition is under-specified. It does not explain the meaning of an 'order', the role of client_name/client_bin, what the tool returns, or any prerequisites, leaving significant gaps for an agent to resolve.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It indirectly maps 'profession' and 'na srok' (for a term) to the profession and days parameters, but gives no meaning for client_name or client_bin, which are required. Partial coverage is insufficient for a low-coverage schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'create an order' for a profession and notes it issues an agent passport and mandate. It does not explicitly differentiate from sibling tools, but the verb and resource are distinct enough to distinguish it from list_professions or order_status.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There are no conditions, exclusions, or references to sibling tools, leaving the agent without context for selection.

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

list_professionsB

Что агенты умеют делать: профессии, их шаги и границы.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not state whether the operation is read-only, what the response looks like, or any side effects. The name 'list' implies a safe read, but the description itself does not confirm this.

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?

The description is a single compact sentence with no wasted words. It communicates the core content efficiently, though the phrasing 'what agents can do' is slightly roundabout rather than a direct operational statement.

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

Completeness3/5

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

Given the simple zero-parameter interface, the description conveys the key content: professions, steps, and boundaries. However, it does not explain the return format or how an agent should interpret the result, and with no output schema or annotations, this missing detail leaves the description only partially complete.

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

Parameters4/5

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

The tool has zero parameters, and the schema coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 applies since no parameter documentation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Что агенты умеют делать: профессии, их шаги и границы' clarifies that the tool exposes available professions along with their steps and constraints. It is sufficiently specific to distinguish it from siblings like create_order or run_step, though it lacks an explicit verb stating 'list'.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool versus alternatives. There is no mention of conditions, prerequisites, or explicit alternatives. The only hint is the subject matter, which implies it is for discovering capabilities, but this is not stated.

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

order_statusC

Состояние заказа: пройденные шаги, отказы и их причины.

ParametersJSON Schema
NameRequiredDescriptionDefault
order_idYes

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses the kind of information returned (passed steps, refusals, reasons) and implicitly signals a read-only operation, but it does not explicitly state side-effect freedom, error behavior, or response shape.

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?

A single short sentence delivers the core meaning with no filler. It is concise and front-loaded, though it is a noun phrase rather than a structured imperative, so it is not a perfect 5.

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

Completeness2/5

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

The tool is simple (one parameter, no output schema), but the description is thin: it names result categories without specifying return format, error cases, or any call context. An agent would have to infer how to present the answer to a user.

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

Parameters2/5

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

The input schema has one self-descriptive order_id string and 0% schema description coverage. The description ties the parameter to an order but adds no detail about where the ID comes from, its format, or valid values, so it does not compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states what the tool reports—order status, completed steps, refusals, and their reasons—which clearly identifies the resource and distinguishes it from mutation tools like create_order or run_step. It is a noun phrase rather than a verb+resource construction, so it loses a point, but the meaning is unambiguous.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as pending_confirmations or verify_journal. The description implies a status-checking use case but never states conditions, prerequisites, or what should trigger this call.

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

pending_confirmationsA

Что сейчас ждёт решения человека. Подтвердить отсюда нельзя — только посмотреть.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It transparently states the tool is view-only ('только посмотреть') and explicitly disclaims confirmation capability, which is critical for an agent to avoid misuse. It does not cover auth, rate limits, or return format, but for a simple read-only list this is adequate.

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?

Two short sentences with no filler. The main purpose is front-loaded and the critical constraint appears immediately after. Every word earns its place.

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?

For a zero-parameter, no-output-schema tool, the description is sufficient: it states what is shown and that it is read-only. It lacks details about the shape of the returned list, but the low complexity lowers the bar.

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

Parameters4/5

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

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds nothing about parameters, but none exist, so no compensation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource: items waiting for human decision. It adds the explicit constraint that confirmation is not possible, only viewing. However, it lacks a specific verb like 'list' or 'show' and does not distinguish itself from sibling tools by name.

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

Usage Guidelines3/5

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

The description implies when to use it (when you want to see pending human decisions) and explicitly states a when-not (cannot confirm from here). It does not mention alternative tools or provide broader usage context, so guidance is limited.

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

run_stepA

Выполнить следующий шаг заказа через шлюз. Необратимое действие остановится и будет ждать человека.

ParametersJSON Schema
NameRequiredDescriptionDefault
order_idYes

TDQS

A3.8/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It explicitly discloses that the action is irreversible and that it will stop and wait for a human – important behavioral traits for an agent. However, it doesn't detail other side effects or what 'wait for a human' entails beyond that.

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?

Two short sentences with no wasteful words. The primary action is front-loaded, and the behavioral warning follows immediately. Everything present earns its place.

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?

For a tool with one simple required parameter and no output schema, the description provides enough for correct invocation: what it does, that it is irreversible, and that human intervention is expected. It could optionally mention what the tool returns, but that is not critical for a step-execution tool.

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 0%, but the parameter order_id is self-explanatory (a string identifier for the order). The description mentions 'заказа', indirectly tying order_id to the order. Yet it adds no detail on format, meaning, or how to obtain the ID.

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?

The description states a specific action ('Выполнить следующий шаг заказа' – execute the next step of the order) and resource ('заказа' – order), plus the gateway context. This distinguishes it from siblings like order_status (status query) and create_order (order creation) without ambiguity.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where sibling tools like pending_confirmations or order_status would be more appropriate.

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

verify_journalA

Проверить целостность журнала действий.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Check integrity' implies a read-only operation, but it does not state side effects, failure behavior, or the form of the result, nor does it clarify what 'integrity' covers (missing entries, contradictions, etc.).

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?

A single sentence that states the action and object with no filler, and the key information is front-loaded. Nothing could be removed without losing meaning.

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

Completeness3/5

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

For a zero-argument tool the call itself is unambiguous, but with no output schema and no annotations the description omits what a successful versus failed verification yields and whether the operation is safe or has side effects. This is the minimum viable level for a simple integrity check.

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

Parameters4/5

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

There are zero parameters, so there is nothing for the description to explain about arguments; the schema's empty properties object already covers 100%. Baseline 4 applies.

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?

The description names a specific action ('Проверить' / check) and a specific resource ('целостность журнала действий' / integrity of the action log). No sibling tool (list_professions, order_status, etc.) overlaps with this purpose, so an agent can distinguish it immediately.

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

Usage Guidelines2/5

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

There is no statement of when to run the verification, what condition should trigger it, or which sibling tool might be an alternative. The agent is left to infer the usage context from the tool name and the bare description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updatesv0.1.0
    • First observedagent_passport
    • First observedcreate_order
    • First observedlist_professions
    • First observedorder_status
    • First observedpending_confirmations
    • First observedrun_step
    • First observedverify_journal
Deploy Server
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

TDQS

B3.3/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct aspect of the workflow: profession discovery, order creation, step execution, status checks, pending human decisions, journal verification, and agent identity. There is no meaningful overlap between tool purposes.

Naming Consistency3/5

Names are consistently lowercase snake_case and generally readable, but the pattern is mixed: list_professions, create_order, run_step, and verify_journal use verb-first naming, while order_status, pending_confirmations, and agent_passport are noun phrases. This is not chaotic, but the two naming styles make the set less predictable.

Tool Count5/5

Seven tools is a well-scoped size for this domain. Each tool covers a necessary part of the order lifecycle without being redundant or excessive.

Completeness4/5

The core workflow is well covered: discover professions, create an order, execute steps, monitor status, see pending confirmations, verify the journal, and inspect the agent passport. The only notable gap is a lack of explicit cancellation or direct confirmation tools, but these may be intentionally handled outside the tool surface.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • forge-agent-gate

    forgeorbital
    A
    license
    Not graded
    quality
    F
    maintenance
    Enables AI agents to execute prediction-market trades through a risk-control gateway that enforces signed mandates and generates proof trails for accountability.
    0
    MIT

  • Dvarapala

    demolished-lab
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides permission gates and tamper-evident audit logging for AI agent tool executions, with declarative policies, consent ladders, and hash-chained verification.
    MIT

  • varco_mcp

    williamselmo1993
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP-compatible AI agents to safely act on business backends by enforcing per-agent permissions, autonomy thresholds, human approval with review-and-edit, and full audit trails.
    MIT

  • nanoGentzen

    DigitLib
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to be governed by formal Gentzen sequent calculus proof trees, with human-in-the-loop approval gates and cryptographic audit trails for consequential actions.
    MIT