tzero-mcp

query_architecture_boundaries

Retrieve active T-4 architectural tier boundaries, import constraints, and zero-leak security rules from local config before designing features to avoid layer violations.

Instructions

Retrieves active T-4 architectural tier boundary definitions, operational constraints, and zero-leak security rules defined in tzero.rules.json or built-in defaults.

Behavior:

Read-only: Reads configuration files; does not modify rules or codebase files.
Idempotent: Returns consistent rule definitions for identical configurations.
100% Offline: Local JSON file lookup without remote calls.

Usage Guidelines:

When to use: Consult before designing new features or adding imports to understand layer isolation rules (e.g. presentation cannot import database models) and avoid architecture violations.
Sibling Routing: To actively validate workspace code against these rules and detect violations, use 'enforce_architecture_boundaries'. To view complete Mermaid topology blueprints, use 'generate_architecture_blueprint'.

Returns: Markdown specification of architectural layers, allowed/forbidden import directions, and security constraints.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`project_root`	No	Root directory of the repository where tzero.rules.json is located (default: current directory).	.
`extra_guidance`	No	Optional custom rules, architecture styles, or conventions to inject into the boundary definition.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Oct 16, 2026

addedInput schema / properties / extra_guidance / description

Added value: +"Optional custom rules, architecture styles, or conventions to inject into the boundary definition."

addedInput schema / properties / project_root / description

Added value: +"Root directory of the repository where tzero.rules.json is located (default: current directory)."

First observedv0.1.0Oct 15, 2026

TDQS

A4.4/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 so well: it declares read-only behavior, idempotency, and that it is 100% offline with no remote calls, which answers the key safety and side-effect questions. It does not cover error/fallback behavior or permission requirements, so it falls short of the top band.

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?

Front-loaded with the core purpose and organized into Behavior, Usage Guidelines, and Returns blocks; each line carries useful information. It is somewhat long for a two-parameter read tool, which keeps it out of the top band.

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

Completeness5/5

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

Given an output schema exists, return details are optional, yet the description still summarizes the Markdown return shape. Combined with the explicit behavior and routing sections, an agent has everything needed to call the tool correctly.

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 description coverage is 100% and both parameters (project_root, extra_guidance) are fully documented in the schema. The description only tangentially reinforces this by mentioning tzero.rules.json lookup, adding little beyond the schema, so the baseline 3 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?

States a specific verb (Retrieves) and a precise resource (active T-4 architectural tier boundary definitions, constraints, and zero-leak security rules), including the source of truth (tzero.rules.json or built-in defaults). An agent can distinguish it immediately from sibling tools like enforce_architecture_boundaries and generate_architecture_blueprint.

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

Usage Guidelines5/5

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

Explicit 'When to use' clause gives a concrete scenario (before designing features or adding imports to understand layer isolation), and 'Sibling Routing' names two alternatives with the exact conditions that select them. Nothing is left to inference.

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