A
licenseA
qualityD
maintenanceExposes a verified tool registry (calculator, sandboxed file read, web fetch) over MCP stdio, enabling any MCP-capable client to reuse the same tools from the inspectable ReAct loop.
3
MIT
TraceGuard Core
by Sigilith
TraceGuard Core
TraceGuard Core includes a Python governance/evidence library and an optional MCP action-name gate.
MCP gate scope
"TRACEGUARD_ALLOWED_ACTIONS": "[\"read_logs\"]"Example configuration:
{
"mcpServers": {
"traceguard-core": {
"command": "uvx",
"args": ["traceguard-core"],
"env": {
"TRACEGUARD_ALLOWED_ACTIONS": "[\"read_logs\"]"
}
}
}
}Related MCP server: agent-firewall
Install
After the 0.1.7 release is published:
python -m pip install traceguard-core==0.1.7The distribution name is traceguard-core; the core Python package is traceguard and the MCP adapter is traceguard_core.
Development tests
Pytest is configured to put src/ first on the import path, preventing the legacy root-level traceguard.py script from shadowing the traceguard package during collection. The release checks run the package contract tests directly; unrelated legacy integration tests are not part of this package test command.
python -m pip install -e '.[test]'
python -m pytest -q tests/test_engine_extra.py tests/test_mcp_gate.pyAvailable Tools
1 tooltraceguard_check_actionA
Return ALLOW or BLOCK for an exact action name using the configured TRACEGUARD_ALLOWED_ACTIONS allowlist. This tool does not execute the action. Arguments are not checked against per-tool schemas.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | Yes | ||
| target_tool | Yes |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add real behavioral context: it names the exact output values (ALLOW/BLOCK), clarifies it is non-executing, and warns that arguments are not validated against per-tool schemas. It omits edge behavior such as what BLOCK means for an unlisted action or error handling, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with the outcome (ALLOW/BLOCK) front-loaded, zero filler, and each sentence contributing a distinct constraint.
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 or annotations exist, but the description supplies the return values and the validation scope, which covers the core of what an agent needs. Missing details about non-matching or malformed action names keep it from being fully 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?
Schema coverage is 0%, so the description must compensate, and it does reasonably: 'exact action name' explains that target_tool must match an allowlist entry verbatim, and the explicit note that arguments are not schema-checked explains the purpose (or non-purpose) of the second parameter. It still does not give the action-name format or an example, leaving some inference.
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 a specific verb and resource: it returns ALLOW or BLOCK for an exact action name against the TRACEGUARD_ALLOWED_ACTIONS allowlist. It is immediately clear what the tool does, though with no sibling tools there is nothing to differentiate it from.
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?
Usage is implied rather than stated: an agent must infer this is a pre-flight policy check to run before performing an action. The scope caveats ('does not execute the action', 'arguments are not checked') clarify boundaries but no explicit when-to-use or alternative is given.
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 tool update
v0.1.8- First observed
traceguard_check_action
TDQS
A3.8/5.0
Scored across 1 tool
Disambiguation5/5
With only a single tool, there is no possibility of confusion or overlap with another tool. The tool's purpose is clearly stated as an allow/block check for exact action names.
Naming Consistency5/5
The single tool name `traceguard_check_action` follows a clear verb_noun snake_case pattern with a consistent prefix. There are no other names to conflict with, so consistency is trivially perfect.
Tool Count2/5
A server named 'TraceGuard Core' with only one tool feels too thin for its apparent scope of policy enforcement. The tool itself is substantive, but a core authorization service typically requires more operations (e.g., managing the allowlist, listing allowed actions).
Completeness2/5
The surface only checks actions against a pre-configured allowlist. There is no way to inspect or modify the allowlist, validate arguments, or execute actions, leaving significant gaps for a policy server. Agents cannot manage or audit the policy through this server.
Related MCP Connectors
Guard wraps stdio MCP servers: risky calls wait for a person; no answer, no run. Remote: cooperative
MCP server (stdio): validate JSON against JSON Schema (draft-07 / 2020-12) via the AgentForge API
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
MCP server (stdio): check if URLs are alive (status, redirects, latency) via the AgentForge API
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceSits in front of any MCP server to enforce allow/ask/block policies on tool calls, paths, shell commands, and network domains, with local approval prompts and an audit log.MIT
- AlicenseBqualityAmaintenanceProvenance gateway for stdio MCP servers. Runs in front of any MCP server, drafts a policy per tool from the server's own schemas, and blocks a tools/call whose destination or content came from an untrusted tool result, regardless of wording. The blocked call is returned as an error result with the provenance chain. Python, Apache-2.0, pip install reasongate.81428 PyPI16Apache 2.0
- AlicenseNot gradedqualityBmaintenanceWraps any stdio MCP server, holding each tool call until a human approves or denies it from their phone, and only then executing the call.MIT