Skip to main content
Glama
Wolfe-Jam

claude-faf-mcp

by Wolfe-Jam
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Fill from the Repo

faf_auto
DestructiveIdempotent

Detect project facts from package.json, Cargo.toml, and other repo files to create or fill project.faf slots, then write CLAUDE.md's faf-managed block and report the faf-cli score before and after.

Instructions

Create /project.faf, or fill the empty slots of the one there, with faf-cli's detection over the repo's own files (package.json, Cargo.toml, pyproject.toml, go.mod…) — no hardcoded defaults. A value already there is kept. A typed None or placeholder word is an empty slot: in a tech slot the app-type uses, only a repo fact replaces it (with no fact it stays as typed); in a tech slot the app-type leaves out, faf_auto writes slotignored; in a 6W it stays as typed (faf_go asks). Every value it changes is listed. Then writes CLAUDE.md's faf-managed block. Returns what was filled and faf-cli's score before and after. faf_go does the human 6Ws.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoProject path. Sets session context for subsequent calls.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv6.0.0
    • removedInput schema / properties / force
      Removed value: -{
-  "description": "Force overwrite existing files",
-  "type": "boolean"
-}
  2. First observedv4.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, the description explains exact fill rules, that existing values are kept, what happens to typed None/placeholder slots, that changes are listed, that CLAUDE.md's faf-managed block is written, and what the tool returns. This gives strong behavioral context for a destructive write tool.

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?

The description is front-loaded with the core action and every sentence carries behavioral detail. It is dense and sentence three is complex, but no content appears purely redundant.

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?

With no output schema, the description supplies the return information: filled values and faf-cli's score before and after. It also covers side effects, slot rules, and the related faf_go boundary, making it complete for this tool.

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 input schema has one parameter with 100% description coverage, so the schema already documents path and its session-context role. The description adds no further meaning about the path parameter, matching the baseline when schema coverage is high.

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?

The description states a specific verb and resource: it creates or fills <folder>/project.faf using repo detection. It also distinguishes its behavior from faf_go by noting that faf_go handles the human 6W questions.

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

Usage Guidelines4/5

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

The description clearly indicates context: use it to auto-fill project.faf from repo facts, and defer human 6W input to faf_go. It does not list every alternative sibling such as faf_init or faf_sync, but the primary usage distinction is explicit.

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