fcop-mcp

Overview Schema Source Related Servers Discussions Admin

Fcop Check

fcop_check

Detects git working tree changes outside allowed task archives and sub-agents signing under multiple roles, by cross-referencing frontmatter and git status to surface audit evidence.

Instructions

FCoP audit. Cross-reference git working tree + frontmatter against the FCoP ledger.

Two independent post-hoc audits, both new in 0.7.1 (fcop_protocol_version: 1.6.0):

Rule 0.a.1 drift — files in git status --porcelain that live outside docs/agents/{tasks,reports,issues,log}/ are by definition work performed without the task→do→report→archive cycle.
Rule 1 sub-agent role impersonation — any session_id that signed files under more than one role code. One session = one role binding for life; cross-role usage is direct evidence that a sub-agent self-claimed a role its parent session was not assigned.

This tool is detection, not prevention. It surfaces the evidence; the protocol-mandated response is for ADMIN to file an ISSUE-* and decide handoff / co-review / distinct-role per Rule 1, just as for the role_occupancy table in fcop_report().

Decomposes to filesystem operations:

git status --porcelain -z from the project root.
Walk every TASK-*.md / REPORT-*.md / ISSUE-*.md in docs/agents/{tasks,reports,issues} + docs/agents/log/*.
Read frontmatter only; never task bodies.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lang`	No	Output language, ``zh`` or ``en``. Default: ``zh``.	zh

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.2.4May 28, 2026

TDQS

A3.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full responsibility. It discloses that the tool only detects and never prevents, describes its filesystem operations (git status --porcelain, scanning TASK/REPORT/ISSUE files, reading frontmatter only), and states it never reads task bodies. This is an unusually detailed behavioral contract.

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?

Lead bold definition is immediately clear, followed by structured numbered and bulleted detail. It is longer than strictly necessary (versioning and protocol-response details add context but could be trimmed), yet nothing is redundant.

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?

Given no annotations and one optional parameter, the description covers what the tool does, how it works at the filesystem level, and the expected follow-up workflow. The presence of an output schema relieves it of explaining return shapes, but it still omits explicit prerequisites (e.g., initialized project/repo) and a direct boundary to fcop_audit.

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?

The schema describes the single lang parameter completely, including default 'zh' and allowed values. The tool description adds no parameter-specific detail, but the baseline 3 is appropriate because the schema coverage is 100%.

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?

States a concrete audit scope: 'Cross-reference git working tree + frontmatter against the FCoP ledger' and enumerates the two specific rules (0.a.1 drift and Rule 1 role impersonation). The phrase 'detection, not prevention' helps separate it from reporting/management tools. It does not explicitly differentiate itself from the sibling fcop_audit, so it misses the top score.

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?

Provides useful context: this is a post-hoc detection audit and the protocol-mandated follow-up is an ADMIN-issued ISSUE-*. However, it never states explicitly when to choose fcop_check over fcop_audit or fcop_report; the closest is an analogy to role_occupancy in fcop_report(). This makes usage guidance implied rather than explicit.

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