A multi-language backend platform for managing MCP connectors, OAuth integrations, custom OpenAPI servers, and AI agent observability with tracing and analytics
This MCP server exposes 19 tools with HTTP transport, but suffers from critical definition gaps. Tool descriptions are present but generic (avg ~60 chars, well below the 194-char baseline). Input schemas are visible and typed, but lack depth: most parameters have minimal descriptions (10-20 chars), violating the pattern:tool-description requirement that every parameter needs a non-empty, actionable description. No output schemas are documented, LLMs cannot infer what fields to expect from responses. Error handling is absent: no recovery guidance, no categorization of retryable vs fatal errors. Security concerns: post_auth_login and post_auth_register expose authentication via tool parameters (email/password), violating pattern:secret-injection. Tool composition is weak: post_oauth_callback accepts both 'code' and direct 'accessToken', creating ambiguous branching logic. No pagination support visible on list tools (get_traces, get_connectors_enabled). Overall, this reads as an early-stage MVP lacking production-grade tool engineering.
Get analytics overview with connector usage, traces, error rates, and anomaly detection
Retrieve the catalog of available connectors with their metadata
Get list of connectors enabled for the current user
Retrieve list of custom MCP servers created by the user
List available OAuth providers for connector authentication
Get list of team members
Get access control policies for agents
Authentication tools expose credentials as parameters (email/password in post_auth_login, post_auth_register). Violates pattern:secret-injection, credentials in tool params are logged in traces and prompt history.
No output schemas documented for any tool. LLMs cannot infer response structure, forcing them to guess field names and types. Violates pattern:tool and pattern:response-shaper.
Parameter descriptions are minimal (10-20 chars avg). E.g., 'connectorId' has description 'The connector ID to enable OAuth for' (40 chars) but lacks format, constraints, or examples. Violates pattern:tool-description baseline of 72 chars avg.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
Retrieve agent execution traces with observability data
Health check endpoint returning service status
Authenticate user and return JWT token
Register a new user and team
Disable a connector for the current user
Enable a connector for the current user
Generate custom MCP server tools from OpenAPI specification snippet
Complete OAuth flow by exchanging authorization code for access token and storing encrypted credentials
Initiate OAuth flow for a connector by generating authorization URL and state token
Invite a new member to the team
Create or update access control policy for an agent
Emit a new agent execution trace for observability
post_oauth_callback accepts both 'code' (OAuth flow) and direct 'accessToken' (alternative flow), creating ambiguous branching. No documentation of which is required, which is optional, or how they interact. Violates pattern:constrained-input.
List tools (get_traces, get_connectors_enabled, get_team_members) lack pagination parameters (limit, offset, page_size). No indication of result limits or how to handle large datasets. Violates pattern:paginated-result.