Fcop Report

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It is exceptionally transparent: it explains the two report shapes, the versions block, the drift warning behavior, the fact that no role assignment is requested in the init report, and the constraints on agent behavior while unbound. This goes well beyond a simple 'returns a report' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured and front-loaded: the core purpose is in the first sentence, followed by clearly separated numbered and bulleted details. The note about the deprecated unbound_report alias earns its place because it prevents confusion with older references. Every sentence adds necessary context.

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

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

The description is complete given the tool's complexity: it covers both call scenarios, the versions/drift block, the output variants, role-assignment behavior, and agent prohibitions. Since an output schema is present, detailed return-value documentation is not required. Nothing an agent needs to call fcop_report correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter, lang, and the input schema already documents it completely with 'Output language, ``zh`` or ``en``. Default: ``zh``.' Schema description coverage is 100%, so the description need not repeat parameter details. A baseline 3 is appropriate because the description adds no parameter-specific value, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific, actionable definition: 'FCoP Rule 0 — first tool call of every new session, also the general project-status report.' It clearly distinguishes the tool from siblings by naming the two report variants (initialization and UNBOUND) and the versions/drift block, so an agent knows exactly what fcop_report does.

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

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

Usage guidance is explicit: call it first in every new session, and the description lists the exact conditions for each report type (missing fcop.json vs. initialized but no role). It also gives exclusions and guardrails, such as 'Agents must NOT invoke redeploy themselves' and prohibitions on reading task bodies or claiming roles while unbound.

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