Skip to main content
Glama

opus-advisor-mcp

Un servidor MCP que permite a Claude Code consultar a Opus como asesor estratégico a mitad de una tarea. Ejecuta tu sesión en Sonnet o Haiku, y escala decisiones complejas a Opus bajo demanda, utilizando tu suscripción existente de Claude Code.

Inspirado en la Estrategia de Asesor de Anthropic.

Cómo funciona

┌─────────────────────────────────────────────┐
│  Claude Code (Sonnet)                       │
│                                             │
│  "I need to decide on the DB schema..."     │
│        │                                    │
│        ▼                                    │
│  calls consult_opus MCP tool                │
│        │                                    │
└────────┼────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────┐
│  opus-advisor MCP server                    │
│                                             │
│  1. Reads prior consultation history        │
│  2. Reads requested files from disk         │
│  3. Pipes prompt to: claude -p --model opus │
│  4. Logs advice to advisor-log.md           │
│  5. Returns advice to Sonnet                │
└─────────────────────────────────────────────┘

No se necesitan claves API. El servidor invoca la CLI claude, que utiliza tu autenticación existente.

Related MCP server: codex-bridge

Instalación

npm install -g opus-advisor-mcp

O clona y compila localmente:

git clone https://github.com/Divinci-AI/opus-advisor-mcp.git
cd opus-advisor-mcp
npm install
npm run build

Configuración

Añádelo al archivo .mcp.json de tu proyecto o a ~/.claude/.mcp.json:

{
  "mcpServers": {
    "opus-advisor": {
      "command": "opus-advisor",
      "timeout": 180000
    }
  }
}

Si se instaló localmente (no globalmente):

{
  "mcpServers": {
    "opus-advisor": {
      "command": "node",
      "args": ["/path/to/opus-advisor-mcp/dist/index.js"],
      "timeout": 180000
    }
  }
}

Reinicia Claude Code después de añadir la configuración.

Herramientas

consult_opus

Consulta a Opus para obtener asesoramiento estratégico.

Parámetro

Tipo

Predeterminado

Descripción

question

string

requerido

La pregunta o problema sobre el que necesitas asesoramiento

context

string

opcional

Contexto adicional, restricciones o antecedentes

files

string[]

opcional

Rutas de archivo (relativas a la raíz del proyecto) para incluir como contexto de código

effort

"low"

"medium"

"high"

"medium"

Nivel de esfuerzo de razonamiento para Opus

include_history

boolean

true

Incluir el historial de consultas previas para mayor continuidad

Ejemplo:

{
  "question": "Is this database migration safe under concurrent writes?",
  "files": ["src/db/migration-042.ts", "src/db/schema.ts"],
  "effort": "high"
}

read_advisor_log

Lee el registro de consultas de llamadas anteriores.

Parámetro

Tipo

Descripción

last_n

number

Número de consultas recientes a devolver (omitir para todas)

read_advisor_meta

Lee metadatos estructurados (latencia, recuento de tokens, niveles de esfuerzo).

Parámetro

Tipo

Descripción

last_n

number

Número de entradas recientes a devolver (omitir para todas)

clear_advisor_log

Borra el registro de consultas y los metadatos para empezar de cero.

Características

  • No requiere clave API — Utiliza tu suscripción existente de Claude Code a través de la CLI claude

  • Registros por proyecto — El historial de consultas se almacena por proyecto en ~/.opus-advisor/<project>-<hash>/

  • Contexto consciente del código — Pasa rutas de archivo directamente; el servidor las lee y las inyecta como bloques de código etiquetados

  • Continuidad de la consulta — El asesoramiento previo se devuelve como contexto para que Opus pueda basarse en decisiones anteriores

  • Historial consciente de tokens — El historial está limitado tanto por recuento de entradas (5) como por presupuesto de tokens (~6K tokens)

  • Seguimiento de metadatos — Latencia, estimaciones de tokens y niveles de esfuerzo rastreados en advisor-meta.jsonl

  • Protección de señales — La salida parcial de procesos terminados se descarta, no se devuelve como asesoramiento

  • Protección contra recorrido de rutas — Las lecturas de archivos se validan para permanecer dentro de la raíz del proyecto

Seguridad

  • Protección contra recorrido de rutas: El parámetro files valida que todas las rutas resueltas permanezcan dentro del directorio raíz del proyecto. Se rechazan rutas como ../../etc/passwd o rutas absolutas fuera del proyecto.

  • Filtrado de archivos binarios: Las extensiones binarias comunes (imágenes, ejecutables, archivos comprimidos, etc.) se omiten automáticamente.

  • Sin ejecución de shell: El servidor utiliza spawn con argumentos de matriz y canaliza el prompt a través de stdin. No ocurre ninguna interpolación de shell.

  • Solo local: El servidor MCP se ejecuta localmente a través de stdio. No se abren puertos de red.

  • Registros de consultas: Almacenados en ~/.opus-advisor/ en texto plano. Estos pueden contener fragmentos de código y preguntas de tus consultas. No confirmes ni compartas estos archivos si contienen código sensible.

Variables de entorno

Variable

Descripción

ADVISOR_LOG_DIR

Sobrescribe el directorio de registro (predeterminado: ~/.opus-advisor/<project>-<hash>/)

Cómo se compara con la herramienta de asesoramiento de Anthropic

La advisor_20260301 de Anthropic es una función de API del lado del servidor donde el asesor ve la transcripción completa de la conversación dentro de una única solicitud de API. Este servidor MCP es un enfoque diferente:

Herramienta de Asesor de Anthropic

opus-advisor-mcp

Compartir contexto

Transcripción completa (lado del servidor)

Pregunta + archivos + historial (lado del cliente)

Autenticación

Se requiere clave API

Utiliza la suscripción existente de Claude Code

Integración

Nivel de API (matriz tools)

Herramienta MCP (funciona en Claude Code hoy)

Persistencia

Ninguna

Registro Markdown + metadatos JSONL

Costo

Facturado por token a tarifas de Opus

Incluido en la suscripción

Requisitos

  • Node.js >= 18

  • CLI de Claude Code instalada y autenticada

Licencia

MIT

Available Tools

4 tools
clear_advisor_logClear Advisor LogA
Destructive

Clear the consultation log and metadata to start fresh for this project.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

The description adds context beyond the destructiveHint annotation by specifying what gets cleared (log and metadata). It is consistent with the annotation and gives agents understanding of the tool's impact.

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, efficient sentence that directly conveys the purpose. No superfluous words, front-loaded with action and resource.

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

Completeness5/5

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

Given the tool's simplicity (zero parameters, no output schema, clear annotations), the description is complete. It tells an agent exactly what the tool does and when to use it.

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

Parameters4/5

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

There are no parameters; the schema coverage is 100%. The description does not need to elaborate on parameters, and it provides no irrelevant information.

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 clearly states the action 'clear' and the resources 'consultation log and metadata'. It distinguishes this tool from the read-only siblings (read_advisor_log, read_advisor_meta).

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 phrase 'to start fresh for this project' implies appropriate usage context. However, it lacks explicit guidance on when not to use or mention of alternatives, though the sibling tool names provide implicit contrast.

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

consult_opusConsult Opus AdvisorA
Read-only

Consult Claude Opus 4.7 for strategic advice. Opus runs via the Claude Code CLI with your existing subscription — no API key needed. The advisor maintains a per-project consultation log for continuity across calls. History is capped by both entry count (5) and token budget (~6K tokens) to prevent context bloat. Use this for architecture decisions, complex debugging, code review, or any problem that benefits from deeper reasoning.

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYesThe question or problem you need advice on. Be specific about what decision you're facing or what you're stuck on.
contextNoAdditional context: relevant code snippets, error messages, constraints, or background. Include enough that the advisor can give specific guidance without needing to read files.
effortNoReasoning effort level for Opus. 'low' for quick opinions, 'medium' (default) for thorough advice, 'high' for deep analysis.medium
filesNoFile paths (relative to project root) to include as code context. Each file is read and prepended as a labeled code block. Max 50KB per file, 200KB total. Example: ['src/index.ts', 'lib/utils.ts']
include_historyNoWhether to include prior consultation history for continuity. Defaults to true. Set to false for standalone questions unrelated to prior advice.

TDQS

A4.6/5.0
Behavior5/5

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

The description reveals multiple behavioral traits beyond annotations: it maintains a per-project consultation log with entry (5) and token (~6K) caps, and explains the subscription model ('no API key needed'). Annotations already mark it as read-only and open-world, and the description adds valuable context without contradiction.

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 approximately 100 words and front-loaded with the main purpose. Every sentence adds value: subscription details, history management, limits, and explicit use cases. No redundancy or filler.

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 and moderate complexity, the description covers the essential aspects: purpose, mechanism, context management, and suitable use cases. It could be slightly improved by mentioning the response format or an example, but overall it is sufficient for an agent to understand the tool.

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

Parameters4/5

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

Schema has 100% coverage for 5 parameters. The description adds value by explaining the history cap (entry count and token budget) that directly informs the include_history parameter. It does not repeat schema descriptions, and the effort parameter's enum is not elaborated, but the overall context aids parameter usage.

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 explicitly states 'Consult Claude Opus 4.7 for strategic advice', providing a clear verb and resource. It distinguishes the tool from its siblings (log management) and lists specific use cases like architecture decisions and complex debugging.

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 clear guidance on when to use the tool ('Use this for architecture decisions, complex debugging, code review'), but does not explicitly mention when not to use it or compare it to alternatives. The siblings are for log management, so no direct competition, but exclusion criteria are missing.

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

read_advisor_logRead Advisor LogA
Read-only

Read the consultation log from prior Opus advisor calls for this project. Useful for reviewing past advice or getting context on decisions already made.

ParametersJSON Schema
NameRequiredDescriptionDefault
last_nNoNumber of recent consultations to return. Omit for the full log.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, and the description adds context about the log's content ('consultation log from prior Opus advisor calls'). There is no contradiction and additional detail is provided.

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?

Two concise sentences, both adding value: first states action, second states usefulness. No extraneous words.

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 the tool's simplicity (one optional param, no output schema), the description adequately explains what data is returned and when to use it. Minor lack of detail on format, but 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% for the only parameter 'last_n', which already explains its meaning. The description does not add further semantics beyond the schema.

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 clearly states the verb 'Read' and the resource 'consultation log from prior Opus advisor calls', and it distinguishes from sibling tools like clear_advisor_log and consult_opus.

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?

It provides context for when to use ('reviewing past advice', 'getting context on decisions'), but does not explicitly mention when not to use or name alternatives like read_advisor_meta.

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

read_advisor_metaRead Advisor MetadataA
Read-only

Read structured metadata (latency, token counts, effort levels) from all consultations. Useful for understanding cost and performance patterns.

ParametersJSON Schema
NameRequiredDescriptionDefault
last_nNoNumber of recent entries to return. Omit for all.

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by specifying the fields read (latency, token counts, effort levels), but does not disclose additional behaviors like behavior on empty results or error handling. For a read-only tool, this is adequate but not comprehensive.

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 extremely concise with only two sentences, front-loading the core action and then stating the use case. Every sentence is meaningful with no superfluous wording.

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?

For a simple tool with one optional parameter and no output schema, the description gives a high-level overview but omits details like return format, data structure, or scope limitations (e.g., 'all consultations' implies no filtering). While siblings provide context, the description alone is moderately complete but could be more thorough.

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% with a clear description of the sole parameter 'last_n'. The tool description does not add any extra meaning or context about the parameter beyond what the schema provides, 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.

Purpose5/5

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

The description clearly states the tool reads structured metadata (latency, token counts, effort levels) from consultations, with a specific verb and resource. It distinguishes from siblings like 'read_advisor_log' and 'clear_advisor_log' by focusing on metadata vs logs, making the purpose unambiguous.

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

Usage Guidelines3/5

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

The description mentions it is 'useful for understanding cost and performance patterns,' implying a use case, but fails to provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, leaving the agent to infer usage context.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv1.1.0
    • First observedclear_advisor_log
    • First observedconsult_opus
    • First observedread_advisor_log
    • First observedread_advisor_meta

TDQS

A4.3/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a uniquely defined purpose: clearing the log, consulting Opus, reading the log, and reading metadata. No two tools overlap in functionality, so an agent can easily distinguish them.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case (e.g., consult_opus, read_advisor_log). The naming convention is uniform across the entire set.

Tool Count5/5

Four tools is a well-scoped count for an advisor MCP server. Each tool addresses a distinct need (consultation, log management, metadata access) without unnecessary extras.

Completeness4/5

The tool set covers the core operations: consultation, log reading/clearing, and metadata inspection. A minor gap is the lack of a configuration tool to adjust Opus parameters, but the current surface is sufficient for most workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Divinci-AI/opus-advisor-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server