Product feedback: agent integrator - MCP prompt misses agent doorway

[venikman]

Context
Standalone FPF product feedback cycle on 2026-05-07 for venikman/fpf-memory. I checked current main, GitHub CI/Pages/Vercel deploy evidence, live GitHub Pages pages, and the hosted public MCP endpoint. The repo and hosted MCP were healthy; this feedback is about the agent-integrator adoption path.

Persona/job
Persona: agent integrator.
Job: connect fpf-memory MCP to a coding agent, verify the public tool surface, and retrieve only the bounded FPF context needed for an agent work packet instead of pasting the whole FPF specification.

Evidence

• Live docs expose a clear product doorway: Start Here links “Use FPF inside an agent conversation” to MCP Recipes, and MCP Recipes says to retrieve compact grounded context instead of pasting the full specification.
• Hosted MCP smoke initialized https://fpf-memory-mcp-vercel-origin.vercel.app/api/mcp/fpf_memory/mcp as fpf_memory v1.0.0 and listed exactly the six public tools: browse_fpf_catalog, search_fpf, ask_fpf, query_fpf_spec, read_fpf_doc, and get_fpf_index_status.
• get_fpf_index_status reported a fresh local_vectorless index with source hash sha256:4bd579472278104ec472ad32f473b51a58d43e6066cc605f7693badcd2ca691d.
• For the agent-integrator prompt “connect fpf-memory MCP to a coding agent, verify public tools, and retrieve only the bounded FPF context needed for a work packet,” ask_fpf returned status: ambiguous with IDs F.18, E.10, and C.24.
• For “using MCP instead of pasting a full specification,” query_fpf_spec returned route:boundary-burden plus A.6, A.6.B, A.6.C, A.6.P, A.6.Q, and A.6.A.
• search_fpf for agent MCP bounded context full spec paste work packet ranked generic pattern hits such as A.2.1 and A.2.3, not the MCP Recipes doorway.
• Live wiki browser smoke also showed that top-level generated destinations are uneven: Routes has destination-local “What this page is” and “Methodology” context, while H.1 and I.3 still feel like generated pattern pages. That is secondary here, but it points to the same product-doc-vs-spec-doc split.

Friction
The agent integrator can connect the endpoint and verify tools, but cannot ask the hosted MCP itself for the “agent use / bounded context / do not paste the full spec” doorway that the product docs advertise. The answer falls back to FPF-internal pattern semantics, so the user has to leave MCP, read website docs, and manually stitch product instructions to spec retrieval.

Proposed improvement
Add an agent-use adoption selector that is available through bounded retrieval, not only the website:

• Add a generated route or catalog entry for “agent use / MCP recipes / bounded context instead of full-spec paste,” or expose product-doc pages such as MCP Recipes through a public read_fpf_doc-style selector.
• Tune ask_fpf / query_fpf_spec so prompts containing “MCP,” “agent,” “bounded context,” “full spec paste,” and “work packet” point first to that agent-use doorway before falling back to boundary-burden or lexicon patterns.
• Keep the response compact: endpoint health, public tools, 3-8 relevant IDs/docs, what not to load, acceptance check, and next move.

Severity
Medium. Core MCP operations work, but the agent-integrator path is exactly where bounded retrieval should replace expensive full-spec context. Missing this doorway increases setup friction and pushes users back toward manual doc reading or large pasted prompts.

Validation path

• Add or tune the agent-use retrieval target.
• Run bun run docs:generate and bun run docs:build if docs change.
• Run hosted/local MCP smoke for get_fpf_index_status, ask_fpf, query_fpf_spec, and read_fpf_doc.
• Dogfood with the prompt: “Use fpf_memory MCP to build an agent work packet without pasting the full FPF. Return route/doc selector, IDs, what not to load, acceptance check, and next move.” The expected result should name the agent-use/MCP Recipes doorway before any deeper FPF pattern route.