Skip to main content
Glama
Sign In
Python MCP Hub

Python MCP Hub

by pzakhim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

validate_plan_slices

Validates versioned implementation plans and linked behavior phases, or legacy plan/task pairs, returning structured rule violations and pass/fail gate status without modifying files.

Instructions

Validate a versioned implementation plan and its linked behavior phases, or a legacy plan/task pair.

Strictly READ-ONLY: Never modifies files in the workspace.
Zero Mock Data: Fails fast on invalid inputs or malformed schemas, returning structured violations.
Versioned plans map ACs to linked phases in one version directory. A scoped UI-only phase is valid.

Args:
    plan_content: Raw text of implementation-plan.md or a legacy plan.
    plan_path: Optional path to docs/features/<module>/<feature>/vN/implementation-plan.md.
    task_content: Legacy task.md content; unused for versioned plans.
    task_path: Legacy task.md path; unused for versioned plans.
    feature_name: Name of the feature module (optional).

Returns:
    Dictionary containing validation status, gate_status (PASSED/FAILED), violations, and checked rules.

Input Schema

NameRequiredDescriptionDefault
plan_pathNo
task_pathNo
feature_nameNo
plan_contentNo
task_contentNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.3.1

TDQS

A4.2/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 disclose key traits: strictly read-only, never modifies workspace files, fails fast on invalid inputs or malformed schemas, and returns structured violations with a gate_status. It does not say whether plan_path is read from disk, how plan_content and plan_path interact if both are supplied, or what happens when neither is given.

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?

Front-loaded with the read-only guarantee and fail-fast behavior before the mechanics, and the Args block is compact with one line per parameter. Nothing is padding, though the Returns section slightly duplicates the output schema.

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?

An output schema exists, so the description is not obligated to explain return values, and it covers the parameter semantics that the 0%-coverage schema omits. It is incomplete on validation rules (what rules or gate criteria are checked) and on the error path when no plan source is supplied.

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 Args block is doing essential work: it explains the format of plan_path, marks feature_name optional, and explicitly scopes task_content/task_path to legacy plans only. The one gap is precedence — it never says whether plan_content or plan_path wins when both are provided, nor what plan_content's relationship to plan_path is.

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 and resource (validate a versioned implementation plan and its linked behavior phases) and explicitly covers the alternate legacy plan/task mode. This clearly separates it from siblings like validate_architecture_code or validate_proposal_spec, which validate different artifacts.

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?

The description explains the two modes and notes that task_content/task_path are unused for versioned plans, which implies selection guidance. However, it never states when to prefer this tool over the sibling validators or what condition routes an agent to the legacy vs versioned path beyond the shape of the inputs.

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

Deploy Server

Other Tools