A SvelteKit web application for FAF (Foundational AI-context Format) - Professional AI-Context Management. Includes contact forms, license management, subscription handling, and email services.
FAF.ONE Svelte is an HTTP-based MCP server with 11 tools covering contact forms, licensing, authentication, and webhooks. The server demonstrates moderate quality: all tools have descriptions and most have complete input schemas with types. However, there are significant gaps in output schema documentation (critical for agent reasoning), parameter descriptions are sometimes generic, and error handling lacks recovery guidance. The tools themselves are functional but not optimized for LLM interaction, naming is descriptive but uses hyphens (contact-form) rather than verb_noun convention, and several tools conflate multiple concerns (fafb-drive-submit handles both validation AND email, stripe-webhook-handler generates licenses AND assigns numbers AND sends emails). Descriptions average ~150 chars (within baseline 194), but parameter annotations are sparse or missing entirely for optional fields. No tool annotations (readOnlyHint/destructiveHint) are present. Overall, this is solid for a production backend but below best-practice for agent-facing tools.
Sends contact form submissions to team@faf.one via Resend with optional auto-reply to submitter. Accepts email, message, name, category (bug/feature/question/feedback), and company fields.
Subscribes email to blog/newsletter. Notifies team@faf.one via Resend, optionally sends auto-reply to subscriber. Falls back to Formspree if Resend fails.
Authenticates user for FAFb 0.9 test-drive. Validates email and password against allowed list and sets secure session cookie.
Logs out user from FAFb 0.9 test-drive by deleting session cookie.
Requests password for FAFb 0.9 test-drive access. Generates and emails a password to allowed email addresses. Implements honeypot (website field) and does not leak the allowed email list.
Submits FAFb 0.9 test-drive answers (Q01-Q22) via email to team@faf.one. Requires user authentication via session cookie. Implements honeypot (website field) and validates required fields.
Output schemas not documented. Tools like fafb-drive-submit, stripe-webhook-handler, and friends-count lack explicit response schemas. Agents cannot plan downstream tool calls or extract required fields (e.g., after validate-license returns, what fields are available? ticket tier? status?). This violates pattern:tool and mxe:response-field-naming.
Tool names do not follow verb_noun convention. Names like 'contact-form', 'fafb-drive-submit', 'friends-count' use hyphens and lack clear action verbs. LLMs parse intent from names first, 'contact-form' is unclear (submit? get? validate?). Should be: send_contact_form, submit_fafb_drive, get_friends_count. Baseline: 90% of A+ tools start with action verbs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Public GET endpoint that returns how many of the 100 numbered Friends of FAF licenses are claimed.
Handles Stripe checkout.session.completed webhooks. Generates license keys, assigns Friends of FAF numbers for $29/yr tier, sends license emails via Resend, and persists licenses to Supabase.
Dev-only license email probe (404 in production). Sends test license email to verify Resend domain verification and email functionality.
Dev-only setup probe (404 in production). Checks environment variables (Supabase, Resend, Stripe), Supabase connectivity, and license count.
Validates license keys for faf-turbo CLI. Checks key format, retrieves license from store, and validates status. Returns tier and status if valid.
Multiple concerns per tool. stripe-webhook-handler generates licenses AND assigns Friends numbers AND sends emails. fafb-drive-submit validates input AND sends email. pattern:tool requires each tool to do exactly one thing so agents can compose them. Split into: generate_license, assign_friends_license, send_license_email; validate_fafb_drive_submission, send_fafb_drive_email.
Parameter descriptions are inconsistent or missing. fafb-drive-submit has 22 parameters (Q01 - Q22) with minimal descriptions. Optional fields like Q02, Q04 - Q18, Q22 lack descriptions entirely, forcing LLMs to infer their meaning. Rule: every parameter needs a description explaining what it controls. Additionally, many descriptions lack expected format/range, e.g., 'Handle (required)' does not explain the expected format, length, or valid characters.
No error recovery guidance. Error responses are generic (e.g., 'Email service not configured', 'Invalid email address'). pattern:recovery-guide requires errors to tell the LLM what to do next. Example: 'Invalid email address, verify format is name@domain.com and try again.' or 'Email service not configured, contact the admin to set RESEND_API_KEY in environment.'
No tool annotations (toolAnnotations: false). Tools like fafb-drive-logout, contact-form (WRITE), stripe-webhook-handler (WRITE) should declare readOnlyHint/destructiveHint/idempotentHint. This helps agents reason about retry safety and side effects. fafb-drive-logout should have destructiveHint=true; friends-count should have readOnlyHint=true. Required by spec 2026-07-28.
Honeypot fields (website) in fafb-drive-submit and fafb-drive-request-password are not mentioned in descriptions. LLMs will not know to pass these fields for bot-detection. Descriptions should clarify: 'website: Honeypot field for spam detection. Leave empty for legitimate requests; if populated, request is silently accepted but not processed.'
No pagination support. Tools that could return multiple items (friends-count implies a count but does not paginate; hypothetically a license listing tool) lack limit/offset/page_size parameters. Baseline pattern:paginated-result requires pagination and total count. This caps context explosion if results grow.
fafb-drive-login and fafb-drive-logout expose session behavior without explaining it. The tool names do not indicate whether they are idempotent. fafb-drive-logout called twice could be idempotent (session already gone) or fail with 'not logged in'. Descriptions should clarify behavior on edge cases. Consider idempotentHint=true for logout.
Dev-only tools (test-setup-probe, test-email-send) return 404 in production but are still registered in the MCP server. This is confusing for agents, they cannot distinguish between 'tool does not exist' and 'tool exists but is unavailable in this environment.' Consider removing them from production tool definitions or clearly documenting environment-based availability in descriptions.