TraceGuard Core
# 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:
```json
{
"mcpServers": {
"traceguard-core": {
"command": "uvx",
"args": ["traceguard-core"],
"env": {
"TRACEGUARD_ALLOWED_ACTIONS": "[\"read_logs\"]"
}
}
}
}
```
## Install
After the 0.1.7 release is published:
```sh
python -m pip install traceguard-core==0.1.7
```
The 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.
```sh
python -m pip install -e '.[test]'
python -m pytest -q tests/test_engine_extra.py tests/test_mcp_gate.py
```
TDQS
Scored across 1 tool
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.
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.
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).
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.