de en es ja ko ru zh

opus-advisor-mcp

Name: opus-advisor-mcp
Author: Divinci-AI

by Divinci-AI

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Local

opus-advisor-mcp

Claude Code가 작업 도중 전략적 조언자로 Opus를 참조할 수 있게 해주는 MCP 서버입니다. Sonnet이나 Haiku로 세션을 실행하고, 필요할 때마다 기존 Claude Code 구독을 사용하여 복잡한 의사 결정을 Opus에게 위임하세요.

Anthropic의 Advisor Strategy에서 영감을 받았습니다.

작동 방식

┌─────────────────────────────────────────────┐
│  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                │
└─────────────────────────────────────────────┘

API 키가 필요하지 않습니다. 이 서버는 기존 인증을 사용하는 claude CLI를 호출합니다.

Related MCP server: codex-bridge

설치

npm install -g opus-advisor-mcp

또는 로컬에서 복제 및 빌드:

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

구성

프로젝트의 .mcp.json 또는 ~/.claude/.mcp.json에 추가하세요:

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

로컬에 설치된 경우(전역 설치가 아님):

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

설정을 추가한 후 Claude Code를 재시작하세요.

도구

`consult_opus`

전략적 조언을 위해 Opus를 참조합니다.

매개변수	유형	기본값	설명
`question`	string	필수	조언이 필요한 질문이나 문제
`context`	string	선택	추가적인 맥락, 제약 조건 또는 배경 정보
`files`	string[]	선택	코드 맥락으로 포함할 파일 경로 (프로젝트 루트 기준)
`effort`	`"low"`	`"medium"`	`"high"`	`"medium"`	Opus의 추론 노력 수준
`include_history`	boolean	`true`	연속성을 위해 이전 상담 기록 포함

예시:

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

`read_advisor_log`

이전 호출의 상담 로그를 읽습니다.

매개변수	유형	설명
`last_n`	number	반환할 최근 상담 횟수 (모두 보려면 생략)

`read_advisor_meta`

구조화된 메타데이터(지연 시간, 토큰 수, 노력 수준)를 읽습니다.

매개변수	유형	설명
`last_n`	number	반환할 최근 항목 수 (모두 보려면 생략)

`clear_advisor_log`

상담 로그와 메타데이터를 삭제하여 새로 시작합니다.

기능

API 키 불필요 — claude CLI를 통해 기존 Claude Code 구독 사용
프로젝트별 로그 — 상담 기록은 프로젝트별로 ~/.opus-advisor/<project>-<hash>/에 저장됨
코드 인식 맥락 — 파일 경로를 직접 전달하면 서버가 이를 읽어 레이블이 지정된 코드 블록으로 삽입함
상담 연속성 — 이전 조언이 맥락으로 다시 제공되어 Opus가 이전 결정을 바탕으로 발전할 수 있음
토큰 인식 기록 — 기록은 항목 수(5개)와 토큰 예산(~6K 토큰)으로 제한됨
메타데이터 추적 — 지연 시간, 토큰 추정치, 노력 수준이 advisor-meta.jsonl에 추적됨
신호 보호 — 강제 종료된 프로세스의 부분 출력은 조언으로 반환되지 않고 폐기됨
경로 탐색 방지 — 파일 읽기는 프로젝트 루트 내에 머무르도록 검증됨

보안

경로 탐색 방지: files 매개변수는 모든 확인된 경로가 프로젝트 루트 디렉토리 내에 있는지 검증합니다. ../../etc/passwd와 같은 경로 또는 프로젝트 외부의 절대 경로는 거부됩니다.
바이너리 파일 필터링: 일반적인 바이너리 확장자(이미지, 실행 파일, 아카이브 등)는 자동으로 건너뜁니다.
쉘 실행 없음: 서버는 배열 인자와 함께 spawn을 사용하며 stdin을 통해 프롬프트를 파이프합니다. 쉘 보간(interpolation)은 발생하지 않습니다.
로컬 전용: MCP 서버는 stdio를 통해 로컬에서 실행됩니다. 네트워크 포트는 열리지 않습니다.
상담 로그: ~/.opus-advisor/에 일반 텍스트로 저장됩니다. 여기에는 상담 내용 중 코드 스니펫과 질문이 포함될 수 있습니다. 민감한 코드가 포함된 경우 이 파일들을 커밋하거나 공유하지 마십시오.

환경 변수

변수	설명
`ADVISOR_LOG_DIR`	로그 디렉토리 재정의 (기본값: `~/.opus-advisor/<project>-<hash>/`)

Anthropic의 Advisor 도구와 비교

Anthropic의 advisor_20260301은 서버 측 API 기능으로, 어드바이저가 단일 API 요청 내에서 전체 대화 기록을 볼 수 있습니다. 이 MCP 서버는 다른 접근 방식을 취합니다:

	Anthropic Advisor 도구	opus-advisor-mcp
맥락 공유	전체 기록 (서버 측)	질문 + 파일 + 기록 (클라이언트 측)
인증	API 키 필요	기존 Claude Code 구독 사용
통합	API 수준 (`tools` 배열)	MCP 도구 (현재 Claude Code에서 작동)
지속성	없음	마크다운 로그 + JSONL 메타데이터
비용	Opus 요금으로 토큰당 청구	구독에 포함

요구 사항

Node.js >= 18
Claude Code CLI 설치 및 인증 완료

라이선스

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

Name	Required	Description	Default
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

Name	Required	Description	Default
`question`	Yes	The question or problem you need advice on. Be specific about what decision you're facing or what you're stuck on.
`context`	No	Additional context: relevant code snippets, error messages, constraints, or background. Include enough that the advisor can give specific guidance without needing to read files.
`effort`	No	Reasoning effort level for Opus. 'low' for quick opinions, 'medium' (default) for thorough advice, 'high' for deep analysis.	medium
`files`	No	File 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_history`	No	Whether 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

Name	Required	Description	Default
`last_n`	No	Number 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

Name	Required	Description	Default
`last_n`	No	Number 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.

4 tool updatesv1.1.0May 7, 2026
- First observedclear_advisor_log
- First observedconsult_opus
- First observedread_advisor_log
- First observedread_advisor_meta

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Scored 2026-05-07 08:15 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

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Writingmate MCPOAuth
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1
DataDoe MCPOAuth
com.datadoe
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
E-commerce & Retail CRM
214

Related MCP Servers

Consult LLM MCP
Code Execution Autonomous Agents
raine
A
license
A
quality
A
maintenance
An MCP server that lets Claude Code consult stronger AI models (o3, Gemini 2.5 Pro, DeepSeek Reasoner) when you need deeper analysis on complex problems.
Updated 2 days ago (2026-09-07 16:30 UTC)
1
102
132
MIT
codex-bridge
Code Analysis Coding Agents Developer Tools
ndcorder
A
license
A
quality
D
maintenance
MCP server that lets Claude Code ask GPT Codex for adversarial planning, code review, debugging, research, and risk triage without leaving your project workflow.
Updated 4 months ago (2026-04-30 16:15 UTC)
9
7
1
MIT
codex-cli-mcp-tool
Code Execution Coding Agents
Mr-Tomahawk
A
license
Not graded
quality
F
maintenance
An MCP server that allows Claude Code to interact with the OpenAI Codex CLI.
Updated a year ago (2025-08-19 07:26 UTC)
21
21
MIT
codex-fusion-mcp
AI & Machine Learning Developer Tools Code Analysis
Tritlo
A
license
Not graded
quality
B
maintenance
MCP server enabling Claude to consult Codex (GPT-5.x) mid-task for second opinions, plan/diff review, brainstorming, and codebase exploration via structured debates and permission-controlled interactions.
Updated 2 months ago (2026-07-06 16:11 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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