A web application for generating evidence-backed go-to-market plans from GitHub repositories. This is a React/TypeScript frontend with Supabase backend and edge functions.
Not an MCP server. No MCP framework or protocol implementation detected. Source code shows Supabase Edge Functions (Deno + HTTP), not MCP. Tools are inferred from function code, not registered via MCP tool registration API.
Parameter schemas lack proper JSON Schema structure. Code-level validation (typeof checks, ALLOWED_ACTIONS constant) exists but is not exposed as formal JSON Schema with type, description, enum, and validation constraints that an MCP client can parse.
No output schemas documented. None of the three functions specify what fields or structure they return. An MCP client cannot know what to expect, breaking downstream tool composition and forcing LLMs to infer response structure.
auth-auditllm-proxysend-email
Recommendations
Migrate to a proper MCP framework (e.g., node-mcp, python-mcp, mcp-golang). This is a web service, not an MCP server. Rewrite as MCP with tool registration, schema definition, and protocol compliance.
For each tool, define a formal JSON Schema for inputs with type, description, enum (where applicable), minimum/maximum, and pattern constraints. Example for auth-audit: { "type": "object", "properties": { "action": { "type": "string", "enum": ["signin", "signout", "password_reset", "password_change", "impersonation", "2fa_enabled"], "description": "Auth action type..." }, ... }, "required": ["action", "success"] }
Rename tools to snake_case verb_noun: auth_audit, llm_proxy → proxy_llm (clearer action), send_email. This aligns with MCP naming conventions and makes tool intent immediately clear to LLMs.
Add enum constraint to llm-proxy's model parameter: ["gpt-4o", "gpt-4o-mini", "gpt-4-turbo"] or equivalent. Validate input before calling OpenAI; return clear error if model is unsupported.
For send-email, enforce mutually-exclusive logic: either (subject + text/html) OR (templateId + dynamicData). Return 400 with message: 'Either provide subject+text/html OR templateId+dynamicData, not both.' before attempting SendGrid call.
Tool naming mixes styles. 'auth-audit' uses hyphens (not verb_noun); 'llm-proxy' is unclear about action (proxy to where?); 'send-email' is verb_noun but hyphenated. MCP tools should use verb_noun snake_case (send_email, audit_auth, proxy_llm) for consistent parsing.
llm-proxy lacks model validation. Description says 'default: gpt-4o-mini' but no enum constraint or validation against supported models. An LLM could pass 'model: invalid_model' and get a 500 error from OpenAI with no guidance on recovery.
send-email conflicting parameter logic. Description says 'subject required if templateId not provided' but parameter schema does not enforce this mutually-exclusive relationship. Code does not validate this constraint either, allowing invalid combos like templateId + missing subject.
Error handling returns raw API errors without recovery guidance. llm-proxy returns OpenAI errors verbatim; send-email returns SendGrid errors without hint on what to retry or fix. Per pattern:recovery-guide, errors should guide the agent toward next steps.
auth-audit has rate limiting (max 20 requests/min per user) documented in description but not enforced in code. No rate-limit headers, no 429 response, no guidance on backoff. Code will silently accept requests beyond limit and insert all of them.
llm-proxy accepts messages parameter without schema or validation. Code does not validate message structure (role, content fields), allowing malformed inputs that OpenAI will reject. Should document expected message format (role enum: system|user|assistant).
No idempotency keys or deduplication. send-email and auth-audit are write operations; agent retries on network failures risk duplicate emails and duplicate audit logs. Should support idempotency_key parameter or request ID to prevent duplicates.
auth-auditsend-email
Add recovery guidance to error responses. E.g., llm-proxy on 401 from OpenAI: 'OpenAI API key missing or invalid. Check OPENAI_API_KEY environment variable.' send-email on rate limit: 'SendGrid rate limit exceeded. Retry after 60 seconds with exponential backoff.'
For auth-audit, actually enforce the 20 requests/min rate limit in code using a token bucket or leaky bucket. Return 429 with Retry-After header on limit exceeded. Store request counts in Redis or similar.
For llm-proxy, validate messages parameter schema before proxying: ensure each message has role (string enum: system|user|assistant) and content (string). Return 400 with validation error if structure is wrong.
Add idempotency support to write operations (auth-audit, send-email). Accept optional idempotency_key parameter; use it as dedup key in database. Return 409 Conflict if same key submitted twice, returning cached response instead of duplicate write.
Add output filtering. llm-proxy currently returns full OpenAI response including model, created timestamp, usage tokens. For chat context, return only: { "choices": [{ "message": { "content": string } }], "usage": {...} }. Strip irrelevant metadata to save tokens.
Document parameter dependencies in descriptions. E.g., send-email description: 'Either provide subject+text/html (custom email) OR templateId+dynamicData (template-based). Cannot provide both. Required fields depend on path chosen.'
Add permission/scope declarations. E.g., auth-audit requires 'write:audit_logs' and valid Supabase session. llm-proxy requires 'read:openai_api' and 'invoke:llm'. send-email requires 'write:email' and SendGrid credentials. Document in tool description.
Implement proper HTTP method validation and CORS. Code has METHOD_NOT_ALLOWED checks, which is good, but consolidate error responses to consistent { "error": string, "code": string, "details": object } format across all functions.