The scv-triage server provides a trusted-local, read-only simulation for evaluating policy verdicts on server and fleet health in a non-production demo environment. It returns deterministic, bounded outputs from a pre-packaged SQLite database—never live infrastructure.
triage_server(hostname, at?): Returns a point-in-time policy verdict (e.g., HEALTHY, CRITICAL, SERVER_OFFLINE, NO_DATA, INDETERMINATE) for a single host, including severity, findings, and non-executable, approval-required actions.
fleet_health(at?): Returns a point-in-time health summary for the entire fleet.
investigate_timeline(hostname, frm, to): Returns a timeline of bounded results over a half-open [frm, to) window; does not infer root causes or exact state-transition times.
Read-only and closed-world: All tools are idempotent, non-destructive, and operate solely on demo data. The server runs only under SCV_RUNTIME_ENVIRONMENT=demo with profiles INCIDENT or CLEAR (switchable via SCV_DEMO_PROFILE).
Semantic validation: Raw evidence undergoes seven layers of validation before a verdict is produced. Rejected evidence yields an INDETERMINATE outcome with a bounded rejection class in findings.kind (e.g., INVALID_REQUEST, OUT_OF_COVERAGE, REQUIRED_EVIDENCE_DEFECTIVE); NO_DATA indicates a valid empty result.
Policy metadata: severity is categorical policy metadata, not impact or confidence (e.g., CRITICAL maps to HIGH, and INDETERMINATE severity HIGH means no trustworthy verdict, not high incident impact).
Non-executable actions: All actions require approval and are never executed by the server.
Simulation profiles: INCIDENT and CLEAR profiles demonstrate different fleet states and point verdicts.
Click on "Install 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., "@scv-triage triage server web-01"
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.
scv-triage-runtime is the Python package that powers this demo. It is a deterministic, trusted-local, non-production, non-live simulation whose three read-only MCP tools return bounded policy verdicts, never live infrastructure state.
graph TB
DB[("Shared demo.sqlite3")]
subgraph boundary["Execution-Boundary MCP Server"]
direction TB
R1["MCP request"] --> RT["Runtime<br/>request validation"]
RT -->|"valid request"| PV["SQLite Provider"]
RT -->|"invalid request"| FC["Bounded Result<br/>INDETERMINATE"]
PV -.->|"read-only query"| DB
PV -->|"raw evidence"| EB["Semantic Evidence Boundary<br/>7 validation layers"]
PV -->|"provider failure"| FC
EB -->|"accepted"| NE["Immutable normalized evidence"]
EB -->|"rejected"| FC
NE --> PL["Policy<br/>deterministic verdict"]
PL --> OUT["Bounded Result<br/>outcome + findings + actions"]
end
subgraph thin["Thin-Wrapper MCP Server"]
direction TB
R2["MCP request"] --> SQL["Source-specific SQL query"]
SQL -.->|"read-only query"| DB
SQL --> RAW["Measurement rows<br/>no verdict, no policy"]
endThe semantic evidence boundary is not a pass-through. It independently validates seven layers, then emits immutable normalized evidence for policy evaluation:
SemanticEvidenceBoundary
├── envelope identity schema, tool, profile match the request
├── request identity hostname, at, frm, to match the request
├── coverage the point or window is inside packaged coverage
├── temporal binding evidence timestamps fall within the request window
├── scope host and fleet scope match the requested target
├── row shape and bounds source, fields, types, and numeric ranges are valid
├── ordering / uniqueness / cap no duplicate keys, monotonic order, fixed cap
└── output guarantee immutable normalized evidencePublic MCP tools:
triage_server(hostname, at?)
fleet_health(at?)
investigate_timeline(hostname, frm, to)
Every result is a simulation snapshot. Lead a point result with its evaluation timestamp; lead a timeline result with its half-open [frm, to) range. Timeline results do not establish an exact state-transition time or root cause.
severity is categorical policy metadata, not a calculation of duration, impact, or confidence. Under the policy, SERVER_OFFLINE maps to HIGH. HEALTHY is not a reservation-availability claim. NO_DATA is a valid empty result; INDETERMINATE means required evidence cannot be reliably evaluated. actions require approval and are non-executable.
For INDETERMINATE, findings.kind names the bounded validation class that stopped evaluation:
Kind | Meaning |
| typed request semantics are invalid |
| a valid point/window is outside packaged coverage |
| the packaged provider returned its closed unavailability signal |
| required evidence is absent, including an empty fleet |
| required evidence is stale or otherwise unusable |
| raw schema or request identity does not match |
| evidence time/window does not match the request |
| evidence escapes the requested or fleet host scope |
| evidence violates uniqueness, order, or the fixed cap |
| a source, row, type, or bounded value is invalid |
A thin provider pass-through may relay data or structured errors, but it does not independently validate request identity, host scope, time/window, order, uniqueness, caps, and payload bounds. The normalized semantic evidence boundary does, and returns one bounded rejection class without backend disclosure when those invariants do not support a trustworthy verdict.
These fixed categories are rejection classes, not exhaustive root causes. They never expose SQL, paths, database/provider identities, raw exception text, or rejected values. Their severity is always HIGH because no trustworthy verdict can be produced—not because incident impact is high. Synthetic failures retain schema-v1 evidence state defective; normal states remain COMPLETE, EMPTY, and NOT_APPLICABLE. Required missing (and an empty fleet) takes precedence over required stale.
Related MCP server: datalox-gated-runtime
Python 3.12 or later
SQLite 3.37 or later (pre-installed on macOS and most Linux)
If your system Python is older than 3.12, install 3.12 first. On Linux without sudo, use uv:
curl -LsSf https://astral.sh/uv/install.sh | sh
uv python install 3.12If pipx is not installed:
curl -sSf https://pipx.pypa.dev/install.py | python3If your system Python is 3.12+, install directly:
pipx install git+https://github.com/kc-ml2/mcp-execution-boundaries.gitIf pipx defaults to an older Python, specify 3.12 explicitly:
pipx install --python 3.12 git+https://github.com/kc-ml2/mcp-execution-boundaries.gitThis puts scv-triage-stdio on your PATH. Most MCP clients find it directly. If yours doesn't, run command -v scv-triage-stdio and paste the output as the command value.
Claude Desktop — edit claude_desktop_config.json:
{
"mcpServers": {
"scv-triage": {
"command": "scv-triage-stdio",
"args": [],
"env": {
"SCV_RUNTIME_ENVIRONMENT": "demo",
"SCV_DEMO_PROFILE": "INCIDENT"
}
}
}
}Cursor — see deploy/cursor-mcp.example.json.
Completely quit and reopen the MCP client. The server is ready when these three tools appear:
triage_server
fleet_health
investigate_timeline
Profile | Fleet state | Point verdicts |
| CRITICAL — storage critical, GPU violation, one server offline | server-01 CRITICAL, server-02 OFFLINE, server-03 HEALTHY |
| HEALTHY — same fleet, no findings | server-01 HEALTHY, server-02 HEALTHY |
At the INCIDENT evaluation point, triage_server(server-01) reports both STORAGE_CRITICAL_ENTRY (CRITICAL) and VIOLATION_PERIOD (HIGH). Co-present findings do not establish causation.
Change SCV_DEMO_PROFILE and restart the client.
After restarting, the client should list exactly three tools: triage_server, fleet_health, and investigate_timeline. If the server doesn't appear, run command -v scv-triage-stdio and use the printed absolute path as the command value instead.
pipx upgrade scv-triage-runtimepipx uninstall scv-triage-runtimegit clone https://github.com/kc-ml2/mcp-execution-boundaries.git
cd mcp-execution-boundaries
python3.12 -m venv .venv
.venv/bin/pip install .For this method, set command to the absolute <repo>/.venv/bin/scv-triage-stdio path.
The server starts only when SCV_RUNTIME_ENVIRONMENT=demo and SCV_DEMO_PROFILE is exactly INCIDENT or CLEAR. Missing, production, or unsupported values abort before MCP protocol startup with no fallback.
MIT — see LICENSE.
Presented at MCP Seoul 2026. See output/ for a structured output comparison between the execution-boundary server and a thin API wrapper on the same query.
Trusted-local, non-production, non-live read-only simulation. Point tools return a point evaluation; investigate_timeline uses a half-open [frm, to) window. Do not infer an exact transition or root cause. Severity is categorical policy metadata, not impact or confidence. INDETERMINATE includes a bounded rejection category in findings.kind; it explains which validation class rejected evidence, never backend details or an exhaustive root cause. Rejection severity HIGH means no trustworthy verdict, not high incident impact. Distinguish NO_DATA from INDETERMINATE. Do not make a reservation claim. Advice is approval-required and non-executable.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds substantial behavioral semantics beyond that: severity is policy metadata not impact or confidence, INDETERMINATE has a bounded rejection category, rejection severity HIGH means no trustworthy verdict, NO_DATA must be distinguished from INDETERMINATE, and advice is approval-required and non-executable. This effectively discloses how to interpret outputs and what not to claim.
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 long, dense paragraph of caveats with no structural organization. While each sentence carries warning value, the accumulation of overlapping disclaimers (severity, rejection, no inference) obscures the core function and makes it hard to scan. The key purpose is buried under behavioral restrictions.
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 description provides rich interpretative context for outputs: point evaluation, severity semantics, INDETERMINATE categories, NO_DATA distinction, and non-executable advice. However, it fails to state what the tool actually returns and does not document the 'at' parameter's semantics. Given the output schema exists, the description covers many caveats but leaves a meaningful gap for a single-parameter tool.
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 only parameter 'at' has no schema description, and the description does not explicitly explain its format or meaning. The phrase 'Point tools return a point evaluation' weakly implies the parameter selects a point in time, but it never confirms that 'at' is a timestamp or describes accepted formats. With 0% schema coverage, the description should compensate more directly; it provides only marginal added meaning.
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 does not clearly state a specific verb and resource (e.g., 'Get fleet health at a point in time'). It opens with 'Trusted-local, non-production, non-live read-only simulation' and mentions 'Point tools return a point evaluation,' which implies the purpose but relies heavily on the tool name. The contrast with investigate_timeline helps, but the primary function remains vague.
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 distinguishes this tool from investigate_timeline by noting the half-open [frm, to) window versus point evaluation, and warns against inferring transitions or root causes. However, it never explicitly states when to choose this tool over the siblings or provides clear exclusion criteria. Usage guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trusted-local, non-production, non-live read-only simulation. Point tools return a point evaluation; investigate_timeline uses a half-open [frm, to) window. Do not infer an exact transition or root cause. Severity is categorical policy metadata, not impact or confidence. INDETERMINATE includes a bounded rejection category in findings.kind; it explains which validation class rejected evidence, never backend details or an exhaustive root cause. Rejection severity HIGH means no trustworthy verdict, not high incident impact. Distinguish NO_DATA from INDETERMINATE. Do not make a reservation claim. Advice is approval-required and non-executable.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| frm | Yes | ||
| hostname | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent hints, the description discloses that this is a 'trusted-local, non-production, non-live' simulation, explains severity is 'categorical policy metadata' not impact or confidence, and details INDETERMINATE and rejection semantics. No contradiction with annotations; it enriches them.
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 dense but every sentence serves a purpose, covering scope, semantics, and pitfalls. It is not redundant or bloated, and it leads with the core nature of the tool. The structure supports skimming for critical constraints.
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?
Given the complexity and existing output schema, the description covers the necessary behavioral context: temporal window semantics, severity interpretation, INDETERMINATE categories, NO_DATA vs INDETERMINATE, and reservation/advice limitations. It is sufficiently thorough for safe and correct 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?
With 0% schema coverage, the description compensates by clarifying frm/to as a half-open window, which is essential for correct use. Hostname is not explicitly discussed, but its role is implied by the tool name and its type is in the schema. The description adds meaningful semantics to the key temporal 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 states the tool is a 'read-only simulation' for investigating timelines, using a half-open [frm, to) window. It clearly distinguishes itself from 'point tools' (siblings) by the temporal evaluation scope. This is a specific verb+resource with clear differentiation.
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?
It explicitly contrasts point tools with the windowed behavior of investigate_timeline, indicating when the tool is appropriate. The numerous 'do not' instructions (e.g., 'do not infer exact transition or root cause', 'do not make a reservation claim') provide critical usage guardrails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trusted-local, non-production, non-live read-only simulation. Point tools return a point evaluation; investigate_timeline uses a half-open [frm, to) window. Do not infer an exact transition or root cause. Severity is categorical policy metadata, not impact or confidence. INDETERMINATE includes a bounded rejection category in findings.kind; it explains which validation class rejected evidence, never backend details or an exhaustive root cause. Rejection severity HIGH means no trustworthy verdict, not high incident impact. Distinguish NO_DATA from INDETERMINATE. Do not make a reservation claim. Advice is approval-required and non-executable.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | ||
| hostname | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnly/idempotent annotations by explaining interpretation pitfalls: severity is policy metadata not impact, HIGH rejection means no trustworthy verdict, INDETERMINATE has a bounded rejection category, and advice is non-executable. These are critical behavioral disclosures that prevent misuse, fully leveraging the description's responsibility.
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 dense paragraph with many caveats. Each sentence adds important interpretation context, but it lacks a clear front-loaded purpose statement and could benefit from bullet points or segmentation. It is appropriately sized for the complexity but not optimally structured.
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 description covers numerous critical caveats about output interpretation (severity, rejection, NO_DATA vs INDETERMINATE, root cause) that are essential for correct use. However, it doesn't explicitly state how the tool behaves for a given hostname or the exact return format, though the output schema likely covers that. Overall, it is quite complete for the tool's complexity.
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%, and the description does not explain the 'at' parameter (presumably a timestamp) or how hostname is used. While hostname is self-explanatory, the lack of any parameter explanation leaves the 'at' parameter ambiguous, and the description does not compensate for the low schema coverage.
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 indicates this is a point evaluation tool for triage, contrasting with investigate_timeline's half-open window. It identifies the tool as a read-only simulation and mentions returning a point evaluation, which gives a clear sense of the action and resource, though not in a single verb+resource phrase.
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?
It contrasts this tool with investigate_timeline by noting investigate_timeline uses a half-open [frm, to) window, implying this tool is for point-in-time evaluation. However, it doesn't explicitly state when to use this tool versus alternatives, nor does it mention fleet_health. The numerous 'Do not' statements are usage constraints but not alternative selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All tool descriptions are identical, so an agent cannot determine what distinguishes triage_server, fleet_health, and investigate_timeline. The names suggest different purposes, but the identical descriptions provide no disambiguating detail, making misselection likely.
Tool names mix conventions: 'triage_server' and 'fleet_health' are noun-style, while 'investigate_timeline' is verb-object. This inconsistency makes it harder to predict tool naming patterns.
With 3 tools, the count is within the well-scoped 3-15 range, but on the lower end for what appears to be a triage/fleet health domain. Each tool likely covers a distinct area, though the set feels slightly thin.
The identical descriptions obscure what each tool actually does, making it impossible to verify coverage. There appear to be significant gaps, such as no way to list individual fleet members or perform bulk triage, leaving agents without needed operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Remote MCP for A2A failure replay MCP, structured receipts, audit logs, and reviewer-ready evidence.
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kc-ml2/mcp-execution-boundaries'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
