How do I use ProfitPilot MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ProfitPilot MCP Server What's our current cash flow projection?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ProfitPilot MCP Server

by rodascaar

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

ProfitPilot MCP Server

Multi-Agent Business Intelligence Architecture - Servidor MCP para inteligencia de negocio especializada en E-commerce que combina el framework QUORUM con agentes especializados en decisiones de negocio.

🌟 Características

ProfitPilot es un sistema de inteligencia de negocio multi-agente diseñado específicamente para E-commerce, que combina el framework QUORUM con agentes especializados en decisiones de negocio.

Los 9 Agentes de ProfitPilot

Agente	Rol Principal	Responsabilidades Clave
Data Intelligence Agent	Analista de Datos	Detecta anomalías, patrones de tráfico, métricas de conversión
Revenue & Margin Agent	Analista de Ingresos	Calcula LTV real, CLV, márgenes por canal, cohort analysis
Financial Modeling Agent	CFO Virtual	Cash flow, working capital, payback period, ROI
Competitor Intelligence Agent	Inteligencia Competitiva	Monitorea precios, promociones, tendencias del mercado
Customer Insight Agent	Analista de Cliente	Churn prediction, NPS, comportamiento de compra
Operations & Inventory Agent	Gestor de Operaciones	Forecasting, stock levels, dead stock, lead times
Scenario & Risk Engine	Gestor de Riesgos	Simulación de escenarios, sensibilidad de margen
Execution Agent	Ejecutor Automático	Ajusta bids, reordena inventario, pausa campañas
Global Constraint Strategist	Estratega Global	Identifica cuellos de botella, prioriza decisiones

Roles de Negocio Soportados

Rol	Preguntas Clave
CEO / Founder	¿Cuánto estamos dejando de ganar por fallas en el checkout? ¿Vale la pena abrir un nuevo canal o doblar el actual?
CMO / Director de Marketing	¿Qué canal me da mejor LTV real? ¿Cómo justifico este presupuesto de ads ante el CFO?
Director de Ecommerce	¿Por qué sube el tráfico pero no las conversiones? ¿Qué productos tengo que descontinuar?
Operations / Supply Chain	¿Cuándo necesito reordenar para no quedarme sin stock? ¿Cuál proveedor me está afectando más el margen con demoras?
Growth / Performance Marketer	¿Cuánto puedo pagar por un cliente antes de perder margen? ¿Qué campaña está quemando presupuesto?
CFO / Finanzas	¿Cuál es el cash flow proyectado si escalo ads? ¿Cómo impacta el inventario en capital de trabajo?

🧠 Deep Reasoning (Auto-Reflexión)

ProfitPilot incluye un sistema de Deep Reasoning inspirado en modelos avanzados como OpenAI o1/o3, GPT-5.2 Pro y Gemini 3 Deep Think. Este sistema permite al agente realizar un proceso de auto-reflexión en bucle, haciéndose preguntas a sí mismo hasta llegar a una conclusión sólida.

Cómo Funciona

Problema → Pensamiento Inicial → ¿Suficiente Info?
                                    ↓
                         No → Generar Pregunta → Responder → Repetir
                                    ↓
                         Sí → Respuesta Final → Verificar

El sistema:

Genera pensamientos iterativos sobre el problema
Se hace preguntas para identificar información faltante
Evalúa el progreso (suficiente, progresando, estancado)
Cambia de enfoque automáticamente cuando está estancado
Aplica auto-crítica para evaluar la calidad de cada pensamiento
Sintetiza todo el proceso en una respuesta final

Configuración

En config.json:

{
  "quorum": {
    "deepReasoning": {
      "maxIterations": 5,
      "minConfidence": 0.7,
      "enableSelfCritique": true,
      "enableApproachChange": true,
      "verbose": false
    }
  }
}

Parámetro	Descripción	Default
`maxIterations`	Máximo de iteraciones de pensamiento	5
`minConfidence`	Confianza mínima para detener (0-1)	0.7
`enableSelfCritique`	Habilitar auto-crítica de calidad	true
`enableApproachChange`	Habilitar cambio de enfoque automático	true
`verbose`	Mostrar progreso detallado en consola	false

Uso

El Deep Reasoning se activa automáticamente para problemas de complejidad estratégica cuando se habilita en las opciones:

await framework.pipeline(problem, {
  enableDeepReasoning: true,
  deepReasoningConfig: {
    maxIterations: 7,
    minConfidence: 0.8
  }
});

Resultado

El resultado incluye:

finalAnswer: Respuesta final generada
thoughtProcess: Array con todas las iteraciones de pensamiento
iterations: Número de iteraciones realizadas
finalConfidence: Confianza final alcanzada
approachChanges: Número de cambios de enfoque
summary: Resumen con insights clave, información faltante y enfoque utilizado

🎛️ Los 4 Modos de Razonamiento

ProfitPilot ofrece 4 modos de razonamiento diferentes, cada uno optimizado para diferentes casos de uso:

Modo	Descripción	Ventajas	Desventajas	Casos de Uso
Retry	Reintenta hasta verificación aprobada, con Deep Reasoning opcional	Simple, bajo costo, respuestas consistentes	No aprende entre intentos	Problemas operacionales y tácticos
Programático	Lógica basada en reglas, keywords y heurísticas sin LLM	Rápido, sin costo, sin dependencia externa	Limitado a patrones conocidos	Preguntas simples, cálculos básicos
Híbrido	Combina programático con LLM según confianza	Balance óptimo costo/calidad, adaptable	Más complejo de configurar	Problemas mixtos (parte simple, parte complejo)
Embebido	Modelos LLM que corren en el proceso Node.js	Privacidad total, sin API externa	Requiere hardware potente, modelos más pequeños	Aplicaciones on-premise, datos sensibles

Configuración

En config.json:

{
  "quorum": {
    "reasoningModes": {
      "defaultMode": "retry",
      "retryConfig": {
        "maxRetries": 3,
        "enableDeepReasoning": true
      },
      "programmaticConfig": {
        "enableKeywordAnalysis": true,
        "enablePatternMatching": true,
        "enableHeuristicRules": true
      },
      "hybridConfig": {
        "llmThreshold": 0.7,
        "programmaticFirst": true
      },
      "embeddedConfig": {
        "modelType": "transformersjs",
        "useWebGPU": false
      }
    }
  }
}

Uso

// Usar modo específico
const result = await framework.reasonWithMode(problem, 'programmatic');

// Usar modo híbrido con configuración personalizada
const hybridResult = await framework.reasonWithMode(problem, 'hybrid', {
  hybridConfig: {
    llmThreshold: 0.8,
    programmaticFirst: true
  }
});

Related MCP server: MCP Business AI Transformation

🧩 Arquitectura Chain of Thought (Nuevo)

ProfitPilot ahora soporta dos arquitecturas diferentes:

1. Modo HTTP (Original)

flowchart LR
    A[Claude Desktop<br/>Modelo: Claude] -->|MCP Protocol| B[profitpilot-mcp-server]
    B -->|HTTP Request| C[LM Studio/Ollama<br/>Modelo Externo]
    
    style A fill:#ffd43b
    style C fill:#74c0fc
    style B fill:#a5d8ff

Requiere: Un LLM externo (LM Studio, Ollama, OpenAI, etc.)
Ventajas: Control total del modelo, puede usar cualquier modelo local
Desventajas: Requiere configuración adicional, dependencia de servicio externo

2. Modo Chain of Thought (Nuevo) ⭐

flowchart LR
    A[Cliente MCP<br/>Claude/Cursor/etc] -->|1. Llamada herramienta| B[profitpilot-mcp-server]
    B -->|2. Prompt de razonamiento| A
    A -->|3. Respuesta pensada| B
    B -->|4. Prompt siguiente paso| A
    A -->|5. Respuesta| B
    B -->|6. Resultado final| A
    
    style A fill:#ffd43b
    style B fill:#a5d8ff

Requiere: Solo el cliente MCP (Claude Desktop, Cursor, etc.)
Ventajas:
- ✅ No requiere LLM externo
- ✅ Usa el modelo del cliente (Claude, GPT-4, etc.)
- ✅ Compatible con cualquier cliente MCP
- ✅ Configuración más simple
- ✅ Menor latencia (sin HTTP)
Desventajas: Depende del modelo del cliente

Herramientas del Modo Chain of Thought

Herramienta	Descripción
`profitpilot_analyze`	Inicia una sesión de razonamiento con el problema
`profitpilot_continue`	Continúa con la respuesta del cliente
`profitpilot_status`	Obtiene el estado actual de la sesión
`profitpilot_reset`	Reinicia una sesión

Flujo de Uso (Chain of Thought)

Cliente llama a profitpilot_analyze con el problema
Servidor genera un prompt estructurado (ej: clasificación de complejidad)
Cliente ejecuta el prompt con su propio modelo
Cliente llama a profitpilot_continue con la respuesta
Servidor procesa y genera el siguiente prompt
Se repite hasta completar el análisis (descomposición, agentes, verificación, síntesis)

Configuración

En config.json:

{
  "mode": "chain-of-thought",
  "modeDescription": "Chain of Thought: Usa el modelo del cliente MCP | http: Usa un LLM externo vía HTTP"
}

Configuración de Claude Desktop

Para usar el modo Chain of Thought, agrega esto a tu configuración:

{
  "mcpServers": {
    "profitpilot-cot": {
      "command": "node",
      "args": ["/ruta/a/profitpilot-mcp-server/dist/index-cot.js"],
      "description": "Modo Chain of Thought: Usa el modelo de Claude Desktop"
    }
  }
}

Para usar el modo HTTP original:

{
  "mcpServers": {
    "profitpilot": {
      "command": "node",
      "args": ["/ruta/a/profitpilot-mcp-server/dist/index.js"],
      "description": "Modo HTTP: Requiere LM Studio u otro LLM externo"
    }
  }
}

📋 Requisitos

Node.js >= 18.0.0
Modo HTTP: Un servidor LLM compatible con OpenAI API (ver opciones abajo)
Modo Chain of Thought: Solo un cliente MCP (Claude Desktop, Cursor, etc.)

Proveedores de LLM Soportados

El servidor MCP es neutro y compatible con cualquier API que siga el estándar OpenAI:

Proveedor	URL Base	Notas
LM Studio	`http://localhost:1234`	Modelos locales
Ollama	`http://localhost:11434`	Modelos locales
OpenAI	`https://api.openai.com/v1`	Requiere API key
vLLM	`http://localhost:8000`	Modelos locales
Text Generation WebUI	`http://localhost:5000`	Modelos locales
Cualquier servidor compatible con OpenAI API	-	-

🚀 Instalación

1. Instalar dependencias

cd profitpilot-mcp-server
npm install

2. Compilar el proyecto

npm run build

3. Configurar el servidor LLM

Elige tu proveedor y configúralo en config.json:

Opción A: LM Studio (Modelos Locales)

Abre LM Studio
Carga un modelo (ej. Qwen2.5 32B, Llama 3.3 70B)
Habilita el servidor API en http://localhost:1234
Verifica que el endpoint /v1/models esté disponible

Opción B: Ollama (Modelos Locales)

Instala Ollama: https://ollama.ai
Ejecuta: ollama pull llama3 (o tu modelo preferido)
Asegúrate que el servidor esté corriendo en http://localhost:11434

Opción C: OpenAI (Cloud)

Obtén una API key de OpenAI
Configura la URL base y API key en config.json

4. Configurar el servidor MCP

Edita config.json según tu proveedor:

{
  "llm": {
    "baseUrl": "http://localhost:1234",
    "defaultModel": "qwen2.5:32b",
    "timeout": 60000,
    "maxRetries": 3,
    "apiKey": ""
  },
  "quorum": {
    "effortRouter": {
      "tactical": { "maxRetries": 1, "agents": ["data-intelligence", "operations"], "subtasks": 1 },
      "operational": { "maxRetries": 2, "agents": ["data-intelligence", "revenue", "customer"], "subtasks": 2 },
      "strategic": { "maxRetries": 3, "agents": ["financial", "scenario", "global-constraint"], "subtasks": 3 }
    }
  }
}

Nota: El campo lmStudio se mantiene por compatibilidad hacia atrás, pero se recomienda usar llm.

🔧 Uso con Claude Desktop

Agrega el servidor a tu configuración de Claude Desktop:

macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`

{
  "mcpServers": {
    "profitpilot": {
      "command": "node",
      "args": ["/Users/home/Downloads/Copia de agente-heavy/profitpilot-mcp-server/dist/index.js"]
    }
  }
}

Windows: `%APPDATA%\\Claude\\claude_desktop_config.json`

{
  "mcpServers": {
    "profitpilot": {
      "command": "node",
      "args": ["C:\\Users\\tu-usuario\\Downloads\\Copia de agente-heavy\\profitpilot-mcp-server\\dist\\index.js"]
    }
  }
}

🛠️ Herramientas MCP Disponibles

`profitpilot_analyze`

Ejecuta el pipeline completo de ProfitPilot para resolver problemas de negocio de ecommerce usando multi-agent reasoning.

Parámetros:

problem (string, requerido): El problema o pregunta de negocio a resolver
role (string, opcional): Rol de negocio (ceo, cmo, ecommerce, operations, growth, cfo)
verbose (boolean, opcional): Mostrar progreso detallado del pipeline
model (string, opcional): Modelo específico a usar
temperature (number, opcional): Temperatura para generación (0-1)
enableDeepReasoning (boolean, opcional): Habilitar Deep Reasoning para problemas estratégicos
reasoningMode (string, opcional): Modo de razonamiento (retry, programmatic, hybrid, embedded)

Ejemplo:

¿Debería doblar el presupuesto de ads en Meta o expandir a TikTok?

`profitpilot_revenue`

Analiza revenue y márgenes del ecommerce.

Parámetros:

timeframe (string, requerido): Período de tiempo a analizar
channels (array, opcional): Canales específicos a analizar

Ejemplo:

Analiza revenue y márgenes para los últimos 30 días en Meta Ads y Google Ads

`profitpilot_forecast`

Genera forecast de ventas e inventario.

Parámetros:

horizon (number, requerido): Horizonte de forecast en días
products (array, opcional): Productos específicos a forecast
confidence (number, opcional): Nivel de confianza deseado (0-1)

Ejemplo:

Genera forecast de ventas para los próximos 90 días

`profitpilot_scenario`

Simula escenarios de negocio para evaluar riesgos y oportunidades.

Parámetros:

scenarioType (string, requerido): Tipo de escenario (cpa_change, price_change, stock_delay, competitor_action, custom)
parameters (object, requerido): Parámetros del escenario

Ejemplo:

Simula qué pasa si Meta sube el CPA 20%

`profitpilot_optimize`

Genera acciones de optimización para el ecommerce.

Parámetros:

target (string, requerido): Objetivo de optimización
constraints (object, opcional): Restricciones para la optimización
autoExecute (boolean, opcional): Ejecutar acciones automáticamente

Ejemplo:

Optimiza para maximizar ROAS con un presupuesto de $10,000

`profitpilot_risk`

Evalúa riesgos de decisiones de negocio.

Parámetros:

decision (string, requerido): Decisión a evaluar
factors (array, opcional): Factores a considerar

Ejemplo:

Evalúa los riesgos de expandir a TikTok

`profitpilot_competitor`

Analiza competidores y mercado.

Parámetros:

competitors (array, requerido): Lista de competidores a analizar
metrics (array, opcional): Métricas específicas a analizar

Ejemplo:

Analiza precios y estrategias de Competidor A y Competidor B

`profitpilot_customer`

Analiza segmentos de clientes y comportamiento.

Parámetros:

segment (string, opcional): Segmento específico a analizar
metrics (array, opcional): Métricas específicas a analizar

Ejemplo:

Analiza segmentos de clientes y riesgo de churn

`profitpilot_constraints`

Analiza cuellos de botella globales usando Teoría de Restricciones.

Parámetros: Ninguno

Ejemplo:

Identifica el cuello de botella que frena el crecimiento

📊 Arquitectura del Sistema

INPUT → [Effort Router] → [Decomposer] → [Agent Pool] → [Synthesis] → [Verification] → OUTPUT
         TÁCTICA/          Subtareas      9 Agentes       Consenso         Puntaje 1-10
         OPERACIONAL/                       Especializados
         ESTRATÉGICA

Pipeline QUORUM

Effort Router: Clasifica la complejidad del problema (táctica/operativa/estratégica)
Decomposer: Descompone el problema en sub-tareas independientes
Agent Pool: Ejecuta múltiples agentes especializados en paralelo
Synthesis Engine: Sintetiza las respuestas con balanced prompting
Verification Pass: Verifica la calidad antes de responder (puntaje 1-10)
Retry Loop: Reintenta si la verificación falla

💡 Diferenciadores Clave de ProfitPilot

CFO Agent: Único sistema que modela cash flow y working capital, no solo métricas de marketing
Global Constraint Engine: Identifica cuellos de botella cross-departamento usando teoría de restricciones
Scenario & Risk Engine: Simulación de escenarios con sensibilidad de margen
Execution Agent: Capacidad de ejecución automática (opcional) para acciones tácticas
Role-Based Routing: Respuestas adaptadas al rol del usuario (CEO, CMO, CFO, etc.)

📚 Documentación

types.ts - Tipos principales del sistema
lmstudio-client.ts - Cliente para LM Studio API
quorum-framework.ts - Framework QUORUM base
profitpilot-framework.ts - Framework ProfitPilot específico
agents/ - Agentes especializados
index.ts - Entry point del servidor MCP

🤝 Contribuciones

Este proyecto está en desarrollo activo. Las contribuciones son bienvenidas.

📄 Licencia

MIT License - Ver archivo LICENSE para más detalles.

Available Tools

4 tools

profitpilot_analyzeA

Ejecuta el pipeline completo de ProfitPilot usando Chain of Thought.

Este servidor NO usa LLMs externos. Genera prompts estructurados que el cliente MCP debe ejecutar con su propio modelo.

El flujo es:

Cliente llama a profitpilot_analyze con el problema
Servidor genera un prompt de razonamiento
Cliente ejecuta el prompt con su modelo
Cliente llama a profitpilot_continue con la respuesta
Se repite hasta completar el análisis

ProfitPilot combina agentes especializados en:

Data Intelligence (análisis de métricas y anomalías)
Revenue & Margin (LTV, CLV, márgenes por canal)
Financial Modeling (cash flow, working capital, payback)
Competitor Intelligence (precios, tendencias del mercado)
Customer Insight (comportamiento, churn prediction)
Operations & Inventory (forecasting, stock levels)
Scenario & Risk Engine (simulación de escenarios)
Execution Agent (acciones automáticas)
Global Constraint Strategist (cuellos de botella globales)

ParametersJSON Schema

Name	Required	Description	Default
`role`	No	Rol de negocio (ceo, cmo, ecommerce, operations, growth, cfo)	cmo
`problem`	Yes	El problema o pregunta de negocio a resolver
`verbose`	No	Mostrar progreso detallado del pipeline
`sessionId`	No	ID de sesión único (opcional, se genera uno si no se proporciona)

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly reveals key traits: the server does not call external LLMs, it produces structured prompts for the client to execute, and the analysis is multi-turn. This materially prevents an agent from assuming the tool runs a local model or returns a final answer immediately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but earned: the flow list and agent domains are organized and relevant. The main behavioral facts are front-loaded, and the detail supports correct multi-step usage rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately conveys what the first call produces (a reasoning prompt) and outlines the full interaction pattern. It does not detail error or session lifecycle behavior, but for an initial invocation tool the guidance is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents role, problem, verbose, and sessionId. The description adds little beyond tying 'problem' to the flow and noting the client later sends a response; this is marginal but acceptable given the schema's completeness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete verb and resource: it executes the full ProfitPilot pipeline using Chain of Thought. It then names profitpilot_continue in the numbered flow, making the division of labor between the two sibling tools explicit. Even though 'completo' is slightly broad, the flow makes clear this is the entry point for the iterative analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The numbered flow states exactly when analyze should be called (with the problem) and when continue should be called (with the model's response), and notes the cycle repeats until complete. It does not explicitly say when to use status or reset instead, but the core when-to-use guidance is present and unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

profitpilot_continueA

Continúa una sesión de razonamiento con la respuesta del cliente.

Debe llamarse después de ejecutar el prompt generado por profitpilot_analyze o profitpilot_continue.

ParametersJSON Schema

Name	Required	Description	Default
`response`	Yes	Respuesta del cliente al prompt anterior
`sessionId`	Yes	ID de sesión (obtenido de profitpilot_analyze)

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of explaining behavior. It does disclose that the tool continues a reasoning session using the client's response and that it requires a prior generated prompt. However, it does not explain side effects such as session state advancement, whether the call is reversible, what happens on invalid sessionId, or what output the agent should expect next.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no redundant filler. It front-loads the core action in the first sentence and adds the critical usage precondition in the second. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description and schema together explain the tool's purpose, required parameters, and workflow position. However, there is no output schema, and the description does not clarify what the tool returns or how the agent should continue afterwards. For a stateful, iterative reasoning tool, that missing behavioral outcome is a noticeable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description adds minimal semantic value beyond the schema: 'respuesta del cliente' aligns with the response parameter, and sessionId is already described as coming from profitpilot_analyze. There is no meaningful enrichment beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Continúa una sesión de razonamiento con la respuesta del cliente' – it clearly identifies the continuation action. It also differentiates from profitpilot_analyze by stating that this tool must be called after executing the prompt generated by profitpilot_analyze. However, it does not explicitly contrast against profitpilot_status or profitpilot_reset, so it falls slightly short of a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear precondition: 'Debe llamarse después de ejecutar el prompt generado por profitpilot_analyze o profitpilot_continue.' This tells the agent exactly when in the workflow to invoke the tool. It does not provide exclusions or direct alternatives, but the sequencing guidance is explicit and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

profitpilot_resetC

Reinicia una sesión de razonamiento.

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	ID de sesión

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden of behavioral disclosure. It states that the session is restarted, but it does not explain what is destroyed or cleared, whether an active session is required, whether the operation is idempotent, or whether prior reasoning is lost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short, front-loaded sentence with no filler words. It is concise, though it sacrifices helpful behavioral context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and the presence of sibling reasoning-session tools, the description is not complete enough. It does not explain the effect of a reset, the response format, or when resetting is preferable to continuing or analyzing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter with 100% schema description coverage. The description adds no parameter detail, but the schema already documents 'sessionId' sufficiently, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action, 'Reinicia' (restarts), and a specific resource, 'una sesión de razonamiento'. It makes the core purpose clear but does not explicitly distinguish it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no guidance on when to use this tool versus sibling tools like profitpilot_continue or profitpilot_status. The usage is only implied by the verb 'reinsicia'; there are no conditions, exclusions, or alternatives mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

profitpilot_statusA

Obtiene el estado actual de una sesión de razonamiento.

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	ID de sesión

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It conveys a read-only behavior by saying 'obtiene' (gets) and 'estado actual' (current status), which implies it does not modify the session. However, it does not disclose return format, whether it can be polled, or error behavior, so transparency is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that immediately states the tool's purpose. No filler or redundant material is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter, but without an output schema or annotations, the description leaves out what the current status looks like, possible status values, and any usage caveats. It is minimally viable but not fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: sessionId is documented as 'ID de sesón'. The tool description adds no additional meaning about the parameter, such as format, constraints, or examples, so it is adequate but not enriched.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Obtiene el estado actual de una sesión de razonamiento' (gets the current status of a reasoning session). This clearly distinguishes it from siblings like analyze, continue, and reset, which imply different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance about when to use this tool versus alternatives such as analyze, continue, or reset. The only clue is the tool name and the word 'status', which implies reading session status, but no conditions or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Aug 30, 2026
- First observedprofitpilot_analyze
- First observedprofitpilot_continue
- First observedprofitpilot_reset
- First observedprofitpilot_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-08-30 13:20 across 4 tools

Disambiguation5/5

Each tool occupies a distinct phase in the session lifecycle: analyze starts, continue advances, status inspects, and reset clears. There is no overlap, and the sequential dependency between analyze and continue is clearly documented.

Naming Consistency4/5

All tools share the consistent profitpilot_ prefix and lowercase snake_case style. Three use verbs (analyze, continue, reset), while status is a noun rather than get_status, which is a minor naming deviation.

Tool Count5/5

Four tools is a well-scoped surface for a session-driven reasoning workflow. Each operation is essential for starting, continuing, inspecting, and resetting a session, with no redundant tools.

Completeness4/5

The core session lifecycle is covered: start, continue, inspect status, and reset. The main gap is the lack of an explicit final-report retrieval endpoint, though status may partially cover this and the client already holds the model responses.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Hive Consult A
io.github.srotzin
Agent-to-agent reasoning-as-a-service: chain-of-thought, analysis, and decision support.
AI & Machine Learning Autonomous Agents
42
conjure
ing.conjure
Agentic commerce.
E-commerce & Retail Autonomous Agents
2
QualeQuest — AI Agent Governance PlatformOAuth
com.qualequest
Multi-agent governance: task orchestration, compliance, decision validation, and ML predictions.
Autonomous Agents AI & Machine Learning
2
FinCore Agentic Commerce A
io.github.athenalion
Agentic commerce with 58 MCP tools for product search, checkout, A2A negotiation, C-Suite analytics.
E-commerce & Retail Autonomous Agents
2

Related MCP Servers

MCP-RAG
RAG Systems Agent Orchestration
ANSH-RIYAL
F
license
Not graded
quality
D
maintenance
An agentic AI system that orchestrates multiple specialized AI tools to perform business analytics and knowledge retrieval, allowing users to analyze data and access business information through natural language queries.
Updated a year ago (2025-06-24 04:32 UTC)
4
-
MCP Business AI Transformation
Agent Orchestration Autonomous Agents RAG Systems
DemoDaygit
F
license
Not graded
quality
D
maintenance
Enterprise-grade MCP server with multi-agent system that enables AI-powered business transformation across finance, healthcare, retail, manufacturing, and technology domains through specialized agents for data analysis, API execution, and report generation.
Updated 10 months ago (2025-12-04 05:01 UTC)
1
-
MCP Business AI Transformation
Agent Orchestration Observability Autonomous Agents
Vovchansky6
F
license
Not graded
quality
C
maintenance
Enterprise-grade MCP server with multi-agent system for business AI transformation across finance, healthcare, retail, and other domains. Provides specialized AI agents for data analysis, API execution, business validation, and report generation with real-time monitoring and observability.
Updated 9 months ago (2025-12-12 17:37 UTC)
-
MCP Multi-Agent Server
Agent Orchestration Autonomous Agents Workplace & Productivity
sunnylabtv-crypto
A
license
Not graded
quality
C
maintenance
A multi-domain multi-agent system served over MCP (Model Context Protocol) with FastMCP, exposing specialized domain agents as tools to automate business workflows.
Updated 2 months ago (2026-08-05 05:58 UTC)
MIT

ProfitPilot MCP Server

🌟 Características

Los 9 Agentes de ProfitPilot

Roles de Negocio Soportados

🧠 Deep Reasoning (Auto-Reflexión)

Cómo Funciona

Configuración

Uso

Resultado

🎛️ Los 4 Modos de Razonamiento

Configuración

Uso

🧩 Arquitectura Chain of Thought (Nuevo)

1. Modo HTTP (Original)

2. Modo Chain of Thought (Nuevo) ⭐

Herramientas del Modo Chain of Thought

Flujo de Uso (Chain of Thought)

Configuración

Configuración de Claude Desktop

📋 Requisitos

Proveedores de LLM Soportados

🚀 Instalación

1. Instalar dependencias

2. Compilar el proyecto

3. Configurar el servidor LLM

Opción A: LM Studio (Modelos Locales)

Opción B: Ollama (Modelos Locales)

Opción C: OpenAI (Cloud)

4. Configurar el servidor MCP

🔧 Uso con Claude Desktop

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\\Claude\\claude_desktop_config.json

🛠️ Herramientas MCP Disponibles

profitpilot_analyze

profitpilot_revenue

profitpilot_forecast

profitpilot_scenario

profitpilot_optimize

profitpilot_risk

profitpilot_competitor

profitpilot_customer

profitpilot_constraints

📊 Arquitectura del Sistema

Pipeline QUORUM

💡 Diferenciadores Clave de ProfitPilot

📚 Documentación

🤝 Contribuciones

📄 Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`

Windows: `%APPDATA%\\Claude\\claude_desktop_config.json`

`profitpilot_analyze`

`profitpilot_revenue`

`profitpilot_forecast`

`profitpilot_scenario`

`profitpilot_optimize`

`profitpilot_risk`

`profitpilot_competitor`

`profitpilot_customer`

`profitpilot_constraints`