A collection of multiple application projects including AI Gateway, consumer tools (cost segregation, DFW CRE analyzer, EdgeDesk, stock wheel strategy screener), and Luma Pediatrics website.
Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This MCP server exhibits severe deficiencies across definition quality. The codebase shows multiple isolated HTTP endpoints and services (dfw-cre-analyzer, stock-wheel-strategy-screener, edgedesk, cost-segregation) that are NOT properly exposed as MCP tools with formal schemas. While 24 tools are claimed, most lack visible input schemas, parameter descriptions are minimal or absent, and there is no evidence of proper tool registration with the MCP protocol. The ai-gateway/server.js file shows mock tool definitions (query_contacts, get_forecast, create_incident) that appear to be placeholders returning hardcoded responses, not real tool implementations. The actual consumer services (Next.js apps, Express servers) are standard REST endpoints without MCP tool wrappers. No tools have comprehensive schemas with type definitions and constraints. Error handling is absent. Descriptions are superficial (e.g., 'CRM data access and operations'). This appears to be a portfolio of disparate microservices retrofitted with a single lightweight gateway, not a cohesive MCP server.
No input schemas visible for 15 of 24 tools. Critical tools like 'Salesforce CRM', 'GitHub', 'Azure SQL', 'Elasticsearch', and all 'GET /api/...' endpoints lack any JSON Schema definitions with parameter types and constraints.
Tool names violate verb_noun convention. 11 tools use non-action names ('Salesforce CRM', 'GitHub', 'ServiceNow ITSM', 'Azure SQL', 'Azure Cosmos DB', 'Databricks', 'Elasticsearch', 'Pinecone') or bare HTTP paths ('GET /api/v1/properties') instead of clear action verbs (e.g., 'query_salesforce_crm', 'query_github_repos'). LLMs cannot infer intent from these names.
Salesforce CRMGitHubServiceNow ITSM
Recommendations
Rename all tools to follow verb_noun convention: 'query_salesforce_contacts', 'list_salesforce_crm_accounts', 'fetch_github_repos', 'create_servicenow_incident', 'query_azure_sql', 'get_stock_quote', 'analyze_stock_symbol', 'create_property_record', 'generate_cost_segregation_report'. Action verbs must come first.
Document comprehensive input schemas for ALL tools using JSON Schema with type, description, enum (for constrained values), minLength/maxLength, minimum/maximum (for numbers). Example: POST /api/properties should declare all 10 input fields (address, purchasePrice, landValue, etc.) with types, descriptions, and constraints.
Expand tool descriptions to 50-200 characters, explaining WHAT the tool does, WHEN to use it, and any prerequisites. Example: 'query_contacts: Search Salesforce CRM for customer contacts by name, email, or company. Use this to find existing accounts before creating new records. Returns name, email, phone, and last activity date. Requires Salesforce admin access.'
Add parameter descriptions to every input parameter, specifying format, valid range, enum values, and dependencies. Example for POST /api/analyze: symbol must be 1-10 uppercase letters; timeframe must be 'swing', 'momentum', or 'positional'; style must be 'technical', 'earnings', 'breakout', or 'contrarian'.
Document output schemas for ALL tools. Specify field names, types, and structure. Example: GET /api/quote/:symbol returns {symbol, price, change, percentChange, lastUpdate, previousClose}. Include pagination info (limit, total, nextCursor) if applicable.
Score history
Overall score trend
↑ 13 points across a rubric change (v1 → v2)
32/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
32
2026-07-28+
v2
2026-03-09
F
19
-
v1
GET /api/runsread only27/100
List past pipeline runs
GET /api/runs/:dateread only40/100
Get a specific past pipeline run
GET /api/v1/propertiesread only27/100
Retrieve commercial properties for DFW CRE analysis
GitHubwriteauthsource verified22/100
Code repository operations and CI/CD
POST /api/analyzeread only50/100
Generate analysis for stock symbol with timeframe and style parameters
POST /api/feedbackwrite40/100
Submit feedback on stock wheel strategy analysis
POST /api/propertieswrite50/100
Create a new property for cost segregation
POST /api/reportswrite47/100
Generate a cost segregation report for a property
POST /api/runwrite45/100
Run the daily pipeline for stock wheel strategy screening
POST /api/v1/ingestwriteauth45/100
Live ingestion endpoint supporting Zillow and LoopNet providers for commercial real estate data
Pineconeread onlyauthsource verified23/100
Vector database for embeddings
Salesforce CRMread onlyauthsource verified18/100
CRM data access and operations
ServiceNow ITSMwriteauthsource verified20/100
IT service management
create_incidentwriteauthsource verified37/100
Create an incident ticket in ServiceNow ITSM
get_forecastread onlysource verified38/100
Get weather forecast information
query_contactsread onlyauthsource verified33/100
Query Salesforce CRM for customer contacts and records
Descriptions are generic and under-specified. Examples: 'CRM data access and operations' (26 chars), 'IT service management' (21 chars), 'SQL database queries' (20 chars). None explain WHEN to use the tool vs. alternatives.
Tools are not properly exposed as MCP tool definitions. The ai-gateway/server.js shows mock responses but no formal MCP tool registration (no `tools/list` or tool schema exports). Most endpoints (dfw-cre-analyzer, stock-wheel-strategy-screener, edgedesk, cost-segregation) are standard REST APIs without MCP wrapper logic. This is a portfolio of REST microservices, not an MCP server.
No parameter descriptions for 8 tools that declare parameters. Examples: POST /api/v1/ingest declares 'provider' and 'maxZips' with descriptions, but GET /api/runs/:date's 'date' parameter has a description. Inconsistency suggests incomplete schema definitions. Many tools declare params but lack description text (e.g., symbol parameter in GET /api/quote/:symbol is described but context is minimal).
GET /api/v1/propertiesGET /api/reportGET /api/runs
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract required data without knowing what fields are returned. This violates the pattern requirement that tools document their output schema.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. Write operations (create_incident, POST /api/v1/ingest, POST /api/run, POST /api/feedback, POST /api/properties, POST /api/reports) lack destructiveHint. This is a current (2026-07-28) protocol feature required for production safety.
ai-gateway/server.js appears to be a mock/placeholder implementation returning hardcoded sample responses, not a functional gateway to real services. The modelResponses object has canned strings like 'I'll check the CRM for you' and '✅ **Incident Created**', these are not real API calls or integrations.
query_contactsget_forecastcreate_incident
Add tool annotations to write operations: destructiveHint=true for create_incident, POST /api/properties, POST /api/reports; readOnlyHint=true for all GET methods; idempotentHint=true for tools that safely support retries. This enables production-grade safety.
Implement real error handling: define error types (not_found, permission_denied, rate_limit, timeout, validation_error), return actionable messages ('Property not found. Use GET /api/properties to see available properties.' instead of bare 404), and suggest recovery steps.
Replace mock ai-gateway implementation in ai-gateway/server.js with actual MCP tool registration and real API calls to backend services. Currently returns hardcoded responses; must integrate with real Salesforce, ServiceNow, and other service APIs.
Create a unified MCP tool registry that wraps all HTTP endpoints (dfw-cre-analyzer, stock-wheel-strategy-screener, edgedesk, cost-segregation) as proper MCP tools with normalized naming, descriptions, and schemas. Currently these are disparate REST APIs.
Add confirmation/dry-run support for destructive operations (create_incident, POST /api/ingest, POST /api/properties, POST /api/reports). Agents should not destructively modify state without user confirmation.
Validate all numeric and string inputs against declared constraints (min/max, length, regex pattern). Return validation errors with the exact constraint violated: 'Invalid maxZips: got 10000, must be between 1 and 1000.'
Document dependencies between tools: 'POST /api/analyze requires a valid stock symbol. Use GET /api/quote/:symbol to verify the symbol exists first.' This guides agent planning.
Add result pagination to tools returning lists: GET /api/properties, GET /api/runs, GET /api/reports should accept limit/offset or cursor parameters and return total count. Cap results at 50 items to prevent context window exhaustion.