The server exposes five tools that validate, compare, explain, fingerprint, and render behavior traces against deterministic contracts, without calling any model.
Validate inputs (behaviorlock_validate) — check a contract and up to 100 optional trace files for validity without comparing them.
Compare behavior (behaviorlock_compare) — diff a baseline and candidate trace against a contract of observable behaviors (tool sequences, permissions, formats, verdicts, numbers).
Explain an assertion (behaviorlock_explain) — return a single assertion with the selected baseline/candidate values and the exact reason it passed or drifted.
Fingerprint a trace (behaviorlock_fingerprint) — produce a stable SHA-256 digest of scenario status and observations, excluding run metadata.
Render reports (behaviorlock_render) — compare traces and output JSON, Markdown, standalone HTML, SARIF, or JUnit XML.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@behaviorlock compare baseline and candidate traces"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Fails your CI when an agent's recorded behavior drifts after a model, prompt, memory, or tool change.
Behaviorlock compares two runs your harness already recorded, a baseline and a candidate, against a contract of behaviors that must stay stable: tool sequences, permission decisions, output structure, outcome verdicts, sets, ranks, and bounded numeric metrics. It is for teams that change the model, prompt, memory, policy, or tools under an existing agent. It does not call a model, judge prose, or inspect hidden reasoning.
If you maintain skills without writing code: Behaviorlock does not read your prompts or judge your texts. It compares values your tooling already records before and after a change — and tells you which of the ones you declared important moved further than you allow. Example: a newsletter skill after a model update. Your harness records the length, whether the call to action is present and which salutation was used. The contract says: length may vary by 20 %, the call to action must stay, the salutation must be one of the allowed forms. Behaviorlock reports each of these as compatible, drifted or unknown — in plain sentences you wrote yourself, such as "The call to action is still present" or "The permission decision does not weaken after upgrade." Behaviorlock does not interpret those sentences; the check itself is a short JSON rule next to each one (see The contract below).
representative scenarios
│
├── baseline.trace.json (model A / prompt v3)
└── candidate.trace.json (model B / prompt v4)
│
▼
behaviorlock.json
selectors + deterministic matchers
│
▼
compatible · drifted · unknown + CI gate
│
▼
JSON · Markdown · HTML · SARIF · JUnitBehaviorlock is not on npm. The commands below use the package attached to the v0.1.0 GitHub release. Requires Node.js 20 or newer.
Claude Code (stdio MCP server):
claude mcp add behaviorlock -- npx -y https://github.com/christian140903-sudo/behaviorlock/releases/download/v0.1.0/behaviorlock-0.1.0.tgz serveAny MCP client:
{
"mcpServers": {
"behaviorlock": {
"command": "npx",
"args": [
"-y",
"https://github.com/christian140903-sudo/behaviorlock/releases/download/v0.1.0/behaviorlock-0.1.0.tgz",
"serve"
],
"env": {
"BEHAVIORLOCK_CONTRACT": "/absolute/path/to/behaviorlock.json"
}
}
}
}BEHAVIORLOCK_CONTRACT is optional. The server offers the prompt
gate-agent-upgrade, which walks the agent through defining scenarios,
recording a baseline, and comparing a candidate with behaviorlock_compare.
The tools read the file paths the client passes to them.
git clone https://github.com/christian140903-sudo/behaviorlock.git && cd behaviorlock
npm ci && npm run build
node dist/src/index.js compare \
examples/baseline.trace.json \
examples/candidate.trace.json \
examples/behaviorlock.json --no-writeBehaviorlock PASS — Support agent upgrade
model-a / prompt-v3 → model-b / prompt-v4
6/7 compatible · 0 drifted · 1 unknown
Scenarios: 2 compatible · 0 drifted · 1 unknownBetween the two runs the candidate tightened a permission (ask → deny),
answered in Markdown instead of JSON (both allowed), called the same two tools
in a different order, and got 18 % slower (budget: 25 %). None of that breaks
the contract. One scenario exists only in the candidate; it is reported as
unknown, not as compatible. The default gate passes because every error
assertion is compatible; --strict also requires the warning and info
assertions and therefore fails on that unknown.
Now weaken the permission instead and run the same check:
sed 's/"deny"/"allow"/' examples/candidate.trace.json > drifted.trace.json
node dist/src/index.js compare \
examples/baseline.trace.json drifted.trace.json examples/behaviorlock.json --no-write
echo "exit code: $?"Behaviorlock FAIL — Support agent upgrade
model-a / prompt-v3 → model-b / prompt-v4
5/7 compatible · 1 drifted · 1 unknown
Scenarios: 1 compatible · 1 drifted · 1 unknown
exit code: 1node dist/src/index.js explain permission-not-weaker examples/baseline.trace.json drifted.trace.json examples/behaviorlock.json
prints the one assertion with both selected values (ask, allow) and the
reason: Candidate rank is worse than baseline.
Without --no-write, compare also writes all five report formats to
.behaviorlock/ next to the contract.
To get a behaviorlock command without a clone:
npm install -g https://github.com/christian140903-sudo/behaviorlock/releases/download/v0.1.0/behaviorlock-0.1.0.tgz.
Related MCP server: Thread Contract MCP Server
When you swap the model under an agent, rewrite its prompt, or add a tool, most of its behavior may change, but some of it must not: it still asks before deleting, still calls tools in the approved order, still returns a format your code can parse. A manual spot check covers some of that once; Behaviorlock repeats the same declared checks on every change.
A golden-file diff of the two bundled traces flags every difference: the stricter
permission, the new format, the reordered tools, the latency change, and the new
scenario. It treats ask → deny (stricter, fine) and ask → allow (weaker, not
fine) the same way: as a difference. Behaviorlock checks only what the contract
declares, in the direction the contract gives.
Model-evaluation platforms are useful when a team wants to run providers, score semantic quality, or use an LLM judge. Behaviorlock owns a smaller layer: given two already-recorded runs, did the declared observable behavior remain compatible? In practice that means:
no provider API keys, model adapters, prompts, or network calls;
no judge model that can change the final answer;
no hidden chain-of-thought capture;
no arbitrary shell execution;
the same JSON inputs always produce the same statuses and fingerprints;
a new scenario without a baseline is unknown, not silently compatible.
Behaviorlock or agent-invariants? Both compare a baseline with a candidate, and both are mine. agent-invariants checks rules over an ordered event stream inside a run (approval before a payment tool, no work after a stop, retry limits). Behaviorlock compares values you chose to record (a decision, a tool list, a verdict, a number) between two runs. Use agent-invariants when the rule is about the order of events; use Behaviorlock when the question is whether a recorded value moved in a direction you declared unacceptable.
Any framework can emit the trace. Behaviorlock only requires scenario status and JSON observations:
{
"$schema": "https://raw.githubusercontent.com/christian140903-sudo/behaviorlock/main/trace.schema.json",
"traceVersion": 1,
"run": { "id": "candidate-001", "candidate": "model-b / prompt-v4" },
"scenarios": [
{
"id": "destructive-action",
"status": "completed",
"observations": {
"permission": { "decision": "deny" },
"tools": ["request_permission", "delete_item", "verify_absence"],
"outcome": { "verdict": "satisfied" }
}
}
]
}Trace metadata is excluded from the behavior fingerprint. Scenario order is normalized; array order inside observations remains behavior and is preserved.
Review and redact traces before storing them. Behaviorlock deliberately does not collect provider transcripts for you.
{
"$schema": "https://raw.githubusercontent.com/christian140903-sudo/behaviorlock/main/behaviorlock.schema.json",
"schemaVersion": 1,
"project": { "name": "support-agent" },
"scenarios": [
{
"id": "destructive-action",
"assertions": [
{
"id": "permission-not-weaker",
"statement": "The permission decision does not weaken after upgrade.",
"severity": "error",
"selector": "/observations/permission/decision",
"matcher": {
"op": "rank_not_lower",
"order": ["allow", "ask", "deny"]
},
"limitations": [
"This compares recorded decisions; it does not prove every destructive prompt was tested."
]
}
]
}
]
}Selectors are RFC 6901 JSON Pointers evaluated against the whole scenario, so
contracts can observe /status as well as /observations/....
Matcher | Candidate is compatible when |
| the selector resolves, including explicit |
| it structurally equals a contract value |
| it structurally equals the baseline value |
| a string contains text or an array contains a JSON value |
| it structurally equals one allowed value |
| its array has the same unique members, ignoring order |
| its array preserves exact order and values |
| absolute and/or relative drift stays within budget |
| its configured rank is equal to or better than baseline |
Relational matchers return unknown when the baseline selector is absent.
Type mismatches that make a comparison undefined also return unknown.
behaviorlock init
behaviorlock validate behaviorlock.json baseline.json candidate.json
behaviorlock fingerprint candidate.json
behaviorlock compare baseline.json candidate.json behaviorlock.json
behaviorlock compare baseline.json candidate.json behaviorlock.json --strict
behaviorlock compare baseline.json candidate.json behaviorlock.json \
--formats json,markdown,html,sarif,junit --out artifacts
behaviorlock explain permission-not-weaker baseline.json candidate.json behaviorlock.jsonFrom a clone, use node dist/src/index.js in place of behaviorlock.
Exit codes:
0: every error assertion is compatible;
1: required behavior drifted or is unknown;
2: invalid input or runtime failure.
JSON carries the complete machine-readable comparison and report digest.
Markdown is designed for upgrade review and pull requests.
HTML is standalone, escaped, and marked noindex.
SARIF lists drifted and unknown assertions as findings.
JUnit maps drift to failures and unknowns to skipped tests.
A CI step in your own project, using the release package:
- run: >
npx -y https://github.com/christian140903-sudo/behaviorlock/releases/download/v0.1.0/behaviorlock-0.1.0.tgz
compare baseline.trace.json candidate.trace.json behaviorlock.json
--formats markdown,sarif,junit --out behaviorlock-reportsThe step fails when required behavior drifted or is unknown (exit code 1) and
on invalid input (exit code 2).
The stdio server (see Try it in two minutes) exposes five tools:
behaviorlock_validate
behaviorlock_compare
behaviorlock_explain
behaviorlock_fingerprint
behaviorlock_render
It also exposes the contract schema, trace schema, bundled example, and the
gate-agent-upgrade prompt. From a clone, you can point a client at
node /absolute/path/to/behaviorlock/dist/src/index.js serve after
npm ci && npm run build.
After npm install https://github.com/christian140903-sudo/behaviorlock/releases/download/v0.1.0/behaviorlock-0.1.0.tgz:
import { compareBehavior, renderReport } from 'behaviorlock';
const report = await compareBehavior(
'./baseline.trace.json',
'./candidate.trace.json',
'./behaviorlock.json',
);
console.log(report.summary.gatePassed);
console.log(renderReport(report, 'markdown'));git clone https://github.com/christian140903-sudo/behaviorlock.git && cd behaviorlock
npm ci && npm test # expected: 73 passing (last verified 2026-10-08, Node 22, fresh clone)What the 73 tests cover: all nine matchers including their unknown cases and
the default and strict gates; JSON Pointer selection and schema validation of
contracts and traces; the comparison runtime, fingerprints, and all five report
formats; the CLI commands with exit codes 0, 1 and 2; and the stdio MCP
server end to end (tools, resources, prompt, a comparison over stdio).
What they do not cover: no real agent or model run (all traces are small
hand-written fixtures); no CLI test with a drifted error assertion (drift is
tested at the function level; the drift example above runs it through the CLI);
SARIF and JUnit output are checked for content, not validated against the
official schemas or uploaded to a code-scanning service; CI runs on Linux only
(Node 20, 22, 24); no tests with large traces.
The drift example in Try it in two minutes triggers the failure case on your machine. Two more checks:
npm run test:coverage # same tests with Node's coverage report
npm run smoke:pack # packs the package, installs it in a temp project, runs the CLI and imports the SDKIt does not record traces or run your agent. Your harness writes the JSON, and Behaviorlock trusts it: it does not attest that a trace came from a particular model, prompt, harness, or production run.
It does not judge quality. No semantic equivalence, factual truth, safety, fairness, or hidden reasoning. A passing gate covers only the scenarios and assertions in the contract; missing scenarios and weak selectors create false confidence.
It does not prevent drift; it reports it. Whether a drifted run blocks a release depends on how you wire the exit code into CI.
Numbers are single values, not benchmarks. number_delta compares one
recorded value per selector, with no statistics.
Fingerprints are content digests, not signatures or provenance.
Known issue in 0.1.0: compare --strict prints PASS in the summary
line when only the default gate passed, but correctly exits with 1. Rely on
the exit code.
Details: limitations, security model, contract reference.
Most of the code was written by AI coding agents under my direction. I wrote the specification, set the constraints, decided what to test, reviewed the result and rejected what did not hold. Release decisions and every claim in this README are mine.
The public history starts at the finished 0.1.0 code (one commit on 2026-07-17); the agent sessions behind it are not published. The idea comes from a private agent system of mine; this repository extracts the general mechanism without that system's rules, memory, or logs (ORIGINS.md).
0.1.0 as a GitHub release (2026-07-17), not on npm · experimental · single
maintainer · no known external users · last verified 2026-10-08.
Referenced by MediaPlural/agent-proven: its
agent-regression skill
points to Behaviorlock for deterministic trace comparison. That is a pointer in
another project's documentation, not a usage report.
Version 0.1.x is an early public schema; incompatible changes will be
documented before a stable release. Please report security issues through the
private process in SECURITY.md.
MIT © Christian Bucher
Compare a baseline and candidate trace against deterministic observable-behavior contracts.
| Name | Required | Description | Default |
|---|---|---|---|
| baseline | Yes | ||
| contract | No | ||
| candidate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It mentions 'deterministic' but does not explain what the comparison output looks like, whether it has side effects, or what happens on failure. This is insufficient for a tool that produces a result.
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 description is a single sentence with no filler. It is front-loaded and efficiently communicates the core function.
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?
Without an output schema, the description should explain return values or outcomes. It does not. It also lacks details about the optional contract parameter and what 'compare' means beyond a generic operation.
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 parameter descriptions (0% coverage), and the description does not explain each parameter. It hints at baseline and candidate via phrasing but leaves the 'contract' parameter ambiguous and does not clarify optionality or expected formats.
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 clearly states the tool's action ('Compare'), the resources ('baseline and candidate trace'), and the context ('against deterministic observable-behavior contracts'). It distinguishes itself from sibling tools like render, validate, explain, and fingerprint, which have different purposes.
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?
No guidance is provided on when to use this tool versus alternatives. The sibling tool names imply different functions, but the description does not mention any conditions, exclusions, or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare traces and return one assertion with selected baseline/candidate values and the exact reason.
| Name | Required | Description | Default |
|---|---|---|---|
| baseline | Yes | ||
| contract | No | ||
| assertion | Yes | ||
| candidate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It does mention that values are 'selected' and that a reason is returned, which adds some context, but it fails to mention return format, error behavior, or whether this is a read-only operation. The description is too sparse to cover the behavioral expectations.
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 description is a single sentence, efficiently front-loaded with the verb and primary action. There is no fluff or redundant phrasing. However, it is so compact that it sacrifices necessary detail, but the structure itself is clean.
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?
The tool has 4 parameters, no annotations, and no output schema, yet the description covers only the basics. It does not explain what 'traces' are, the role of 'contract', or what constitutes the 'exact reason'. Given the complexity and lack of structured metadata, the description is incomplete.
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 0%, so the description must clarify parameters. It mentions 'baseline/candidate values', giving some meaning to those two, but 'contract' and 'assertion' are left unexplained. The phrase 'return one assertion' could confuse the 'assertion' parameter with the return value. Overall, only partial parameter insight is provided.
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 clearly states the tool compares traces and returns one assertion with selected baseline/candidate values and the exact reason. It provides a specific verb ('compare') and resource ('assertion'), and the purpose is distinguishable from siblings like 'render' or 'validate', though it overlaps somewhat with 'behaviorlock_compare' which likely does the comparison without the 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?
The description gives no explicit guidance on when to use this tool instead of alternatives like behaviorlock_compare or behaviorlock_validate. It implies use when an explanation is needed, but does not state this directly or list any exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a stable SHA-256 fingerprint of scenario status and observations, excluding run metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| trace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that the operation is stable and excludes run metadata, but it does not explicitly state read-only behavior, output format, or error handling. This adds some useful context but leaves gaps.
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?
Description is a single, front-loaded sentence with no wasted words. It efficiently conveys purpose and key behavioral trait.
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?
Tool is simple (one string input), but the description omits the meaning of the trace parameter and the return format of the fingerprint. It provides enough for basic selection but is not fully complete for invocation.
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 single 'trace' parameter is undocumented in the schema, and the description's phrase 'scenario status and observations' does not explicitly connect to the 'trace' argument. The description does not clarify what should be passed in the trace parameter or its format.
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?
Description clearly states a specific action ('Create a stable SHA-256 fingerprint') and identifies the resource/scope ('scenario status and observations'). It distinguishes from sibling tools (render/validate/compare/explain) by its hash-generation purpose.
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?
Implies usage for fingerprinting scenario state but does not explicitly state when to use it over siblings like behaviorlock_compare. The 'excluding run metadata' hints at a comparison use case, but no direct when-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare traces and render JSON, Markdown, standalone HTML, SARIF, or JUnit XML.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | markdown | |
| baseline | Yes | ||
| contract | No | ||
| candidate | Yes |
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. It does not mention side effects, return types, error behavior, or whether files are written, making the tool's runtime behavior opaque.
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 description is a single, tightly scoped sentence. Every phrase adds information about what the tool does and its supported output formats.
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?
The tool has 4 parameters, no annotations, and no output schema. The description is too sparse to fully contextualize its use, leaving gaps around when to invoke it and what the resulting render looks like.
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 coverage is 0%, so the description must compensate. It hints that baseline and candidate are traces and lists output formats, but it does not explain the 'contract' parameter or add meaning beyond parameter names.
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 clear action: compare traces and render in multiple formats. It differentiates from sibling tools by focusing on rendering outputs, though 'compare' overlaps somewhat with the sibling 'compare' tool.
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?
No explicit guidance on when to use this tool versus alternatives like behaviorlock_compare or behaviorlock_explain. The description implies rendering use cases but does not state exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a behavior contract and optional portable trace files without comparing them.
| Name | Required | Description | Default |
|---|---|---|---|
| traces | No | ||
| contract | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'validate' without explaining whether the tool is read-only, side-effect-free, returns success/failure, or throws errors on invalid input. This is a significant gap for a standalone validation tool.
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 description is a single, front-loaded sentence that directly states the action and scope. There is no redundant information or filler.
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?
The tool is simple, but the description lacks usage context and behavioral transparency. It is minimally adequate for understanding the core action, but the agent needs more details about side effects, return behavior, and when to choose this tool over siblings.
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?
With 0% schema description coverage, the description compensates by labeling 'contract' as a behavior contract and 'traces' as optional portable trace files. However, it does not elaborate on expected formats, constraints, or how the traces relate to the contract, so it only partially bridges the gap.
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 clearly states a specific verb ('validate') and resource ('behavior contract and optional portable trace files'), and adds the distinguishing clause 'without comparing them' to differentiate from the sibling tool behaviorlock_compare. This makes the tool's purpose unmistakable.
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?
The phrase 'without comparing them' implies a separation from comparison, but no explicit when-to-use guidance or alternatives are given. The context is implied rather than explicitly stated, so the agent must infer when to choose validate over render, explain, or fingerprint.
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.
v0.1.0behaviorlock_comparebehaviorlock_explainbehaviorlock_fingerprintbehaviorlock_renderbehaviorlock_validateScored across 5 tools
The five tools have distinct roles: render formats output, validate checks contracts without comparison, compare runs comparisons, explain provides detailed assertion reasoning, and fingerprint generates hashes. While render and explain both involve comparison, their output purposes are clearly differentiated.
All tool names follow a consistent pattern: lowercase snake_case with the server prefix 'behaviorlock_' followed by a single verb. This is uniform and predictable.
Five tools is an appropriate, focused set for a behavior contract comparison utility—not too few, not excessive.
The tool set covers validation, comparison, explanation, rendering, and fingerprinting, providing a complete workflow for observing and debugging behavior-contract compliance.
Decision-assurance for AI agents: an auditable action boundary + receipt before it acts.
Machine-verifiable authorization checks for autonomous AI agents.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Policy-aware AI execution, verification, cost, and trajectory evidence for agents.
