Loading ToolBench
Persistent project context for Claude. IANA-registered .faf format. Core 14 MCP tools (30 with FAF_TOOLS=all).
Critical deficiencies across parameter documentation and input schemas. Most tools lack visible parameter descriptions and formal input schemas in the provided source excerpt. Of 15 tools listed, only faf_read shows a complete input schema with a documented parameter. Tools faf_score and faf_trust have empty 'properties' in their Input field, indicating missing parameters. The tool descriptions themselves are present but very brief (10-50 chars), below the 50-200 char LLM-optimized baseline. No error handling guidance is visible in the source excerpt. The server appears to delegate core logic to faf-cli via FafEngineAdapter, but the MCP tool interface itself lacks the rigor required for reliable agent tool use.
Display information about this claude-faf-mcp server and its capabilities
Automatically detect and configure the project stack from files
In-session proof tool to see the delta yourself
Display the current project context from the .faf file
Check the project's .faf file for issues and provide diagnostics
Write a .faf file to a specific location with explicit context
Build context by question and answer interaction
14 of 15 tools lack visible input schemas. Only faf_read shows a schema with a 'path' parameter. Tools like faf_score, faf_trust show empty 'properties': {}, indicating no parameters are documented. Cannot verify parameter types, constraints, or descriptions for most tools.
Tool descriptions are extremely brief (10-50 characters). The rubric baseline for LLM-optimized descriptions is 50 - 200 chars. Current descriptions like 'Compute the AI-readiness score for the project with parity verification' (67 chars) are at the minimum threshold. Descriptions do not explain WHEN to use each tool vs similar ones, or what the return structure is.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Initialize a .faf file for the active project
Read a file inside the active project (plus FAF_ALLOWED_ROOTS)
Recall and display a previously stored .faf file
Compute the AI-readiness score for the project with parity verification
Set up the SessionStart hook for automated context refresh
Synchronize project context into the active .faf file
Synchronize project context across three-way merge
Verify the parity receipt and integrity of the project context
No visible error handling guidance in tool implementations. The source excerpt shows tool logic but no documented error cases, recovery paths, or user-facing error messages. Agents cannot know whether a failure is retryable, user-fixable, or fatal.
Multiple tools operate on the same .faf file resource (faf_sync, faf_etch, faf_recall, faf_context, faf_init) but their naming does not clearly distinguish between initialization, reading, writing, and three-way merge semantics. faf_etch vs faf_sync vs faf_recall naming is cryptic; LLMs may conflate them.
Output schemas are not documented in the provided source. Agents cannot know what fields to expect from faf_score, faf_context, faf_doctor, faf_trust, or faf_about responses. This prevents downstream tool chaining and forces agents to guess at response structure.
faf_read accepts only a 'path' parameter with minimal description ('The file path to read (relative or absolute)'). No explanation of allowed roots, symlink handling, or size limits. Agents may attempt to read system files outside the confined project directory.
Tools that modify state (faf_init, faf_auto, faf_sync, faf_etch, faf_setup, faf_tri_sync marked as WRITE risk) lack confirmation or dry-run support in visible definitions. Agents may accidentally overwrite project context without an undo path.