MCP server for RudderStack Profiles, enabling interaction with customer data unification, warehouse connections, data discovery, and profile configuration
RudderStack Profiles MCP provides 10 tools with consistent naming (verb_noun patterns) and reasonable descriptions. However, there are significant gaps: (1) Input schemas are inferred from the PR description, not visible in the source code excerpt; (2) Parameter descriptions are present but minimal (avg ~40-60 chars vs baseline 72); (3) No output schemas documented; (4) Error handling is largely absent from tool implementations; (5) Security risks around credentials and validation not addressed; (6) Some tools combine multiple concerns (e.g., profiles_workflow_guide is a catch-all). The server is functional but falls short of production-grade quality.
Get comprehensive information about RudderStack Profiles topics. This consolidated tool provides detailed information about various aspects of RudderStack Profiles including profiles, CLI, project configuration, inputs, models, macros, propensity, and date difference entity variables.
Examine table structure and get column information before configuration. Returns column names and data types for the specified table
Get detailed information about a specific warehouse connection including host, port, schema, and other configuration details
Get a list of available warehouse connections that can be used in your profiles project. This is where the profiles outputs will be written.
Create or verify warehouse connections programmatically. Initialize a connection to a supported data warehouse (Snowflake, BigQuery, Redshift, Databricks, Postgres)
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required data when they don't know what fields will be returned.
Input schemas not visible in source code. Schema documentation appears only in PR description, not in actual code. Parameter 'connection_details' in initialize_warehouse_connection is typed as 'object' with no field-level schema, making it ambiguous.
Credentials passed as parameters. The 'connection_details' parameter in initialize_warehouse_connection likely includes passwords, API keys, or private keys. These should be injected server-side via environment variables or vault, never exposed as tool parameters.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 57 | 1.6.0+ | v1 |
Identify relevant tables for your profiles project based on database and schema. Returns tables that match common event tracking patterns (tracks, pages, identifies, screens)
Comprehensive workflow guidance for RudderStack Profiles tasks. Provides step-by-step recommendations, validation, and next steps based on your current goal and action
Execute SQL queries against your configured warehouse to analyze data and validate table structures
Search RudderStack Profiles documentation using RAG (Retrieval Augmented Generation) to find relevant information and answers to questions
Initialize a new RudderStack Profiles project with required directory structure and configuration files
No error recovery guidance. Tools lack actionable error messages. When initialize_warehouse_connection fails, the LLM gets no suggestion on what to try next (e.g., 'Check credentials with get_connection_details first').
Destructive operations lack confirmation. setup_new_profiles_project creates directories and files but has no dry-run or confirmation step. An agent error could clobber a user's existing project.
profiles_workflow_guide combines multiple concerns: guidance, validation, and next-step recommendation. Split into separate tools (get_workflow_guidance, validate_configuration, suggest_next_steps) for better composability.
Parameter descriptions are minimal (avg 40-60 chars vs baseline 72). Example: 'The database to search for tables' lacks guidance on which database in a multi-warehouse setup. Should clarify 'The warehouse database name (e.g., analytics, events) configured in your connection'.
No pagination support documented. run_query accepts any query but provides no mention of limits or pagination. Large result sets could exhaust context window or cause timeouts.
Missing permission checks. No tool declares required permissions (e.g., 'read:warehouse', 'write:project'). Agents cannot be configured with least-privilege access.
Enum constraints missing for enumerated parameters. 'warehouse_type' in initialize_warehouse_connection lists 5 valid values in description but not in a JSON Schema enum field. LLMs may hallucinate invalid types like 'mysql' or 'mongodb'.