Which integrations are available for this server?

Enables auditing of GitHub repositories to detect drift between portfolio records and actual repository state.

How do I use portfolio-drift-mcp?

1. Click on "Install 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., "@portfolio-drift-mcp audit my portfolio for drift" 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.

portfolio-drift-mcp

by odanree

Overview Schema Related Servers Score Discussions

Python

Remote

portfolio-drift-mcp

MCP server that wraps portfolio-drift-agent — lets LLM clients (Claude Desktop, Claude Code, custom agents) audit a portfolio of projects against GitHub conversationally instead of round-tripping through a terminal.

Why this exists

If you maintain a portfolio of projects (a resume, a profile site, an internal project tracker) the source records drift the moment the underlying repos evolve. portfolio-drift-agent audits that drift via CLI. This server exposes the same audit as MCP tools so an LLM agent can call it mid-conversation:

"Before I push this PR, audit Beacon's own record on my portfolio. If the tech stack is missing anything that just shipped, propose patches and dry-run them."

The model can call audit_single_project, read the response, then call apply_drift_patches with dry_run=true — all without a human typing a command.

Related MCP server: Autonomous QA Engineer MCP

Tools

Tool	Args	Purpose
`audit_portfolio_drift`	`adapter?, limit?, model?`	Full audit. Use `limit` for quick scans — the full ~25-project audit takes 2-3 min.
`audit_single_project`	`project_id, adapter?, model?`	Single project, ~10 seconds.
`apply_drift_patches`	`patches[], dry_run=true`	HITL apply. Dry-run prints intent; pass `dry_run=false` to actually mutate Beacon.

Every tool returns a structured envelope:

{ "ok": true, ...payload }
// or
{ "ok": false, "error_kind": "config|network|not_found|upstream", "error": "..." }

error_kind lets the calling LLM branch deterministically (re-prompt for missing config vs. retry on network vs. give up on not-found) without parsing tracebacks.

Install

pip install git+https://github.com/odanree/portfolio-drift-mcp

Then register in your MCP client (Claude Code example):

claude mcp add portfolio-drift python -m drift_mcp.server \
  --env ANTHROPIC_API_KEY=sk-ant-... \
  --env BEACON_JWT=... \
  --env BEACON_API_URL=https://beacon.danhle.net \
  --env GITHUB_TOKEN=ghp_...

Claude Desktop config (in ~/Library/Application Support/Claude/claude_desktop_config.json or the Windows equivalent):

{
  "mcpServers": {
    "portfolio-drift": {
      "command": "python",
      "args": ["-m", "drift_mcp.server"],
      "env": {
        "ANTHROPIC_API_KEY": "sk-ant-...",
        "BEACON_JWT": "...",
        "BEACON_API_URL": "https://beacon.danhle.net",
        "GITHUB_TOKEN": "ghp_..."
      }
    }
  }
}

Environment

Var	Default	When required
`BEACON_API_URL`	`https://beacon.danhle.net`	Always
`BEACON_JWT`	—	Audit with `adapter="beacon"`; apply with `dry_run=false`
`ANTHROPIC_API_KEY`	—	All audit tools
`GITHUB_TOKEN`	(unauth)	Optional. Raises GitHub rate limit 60/hr → 5000/hr — strongly recommended for non-trivial portfolios.
`DRIFT_MODEL`	`claude-sonnet-4-6`	Anthropic model id used by the analyzer
`DRIFT_STALE_DAYS`	`180`	Project is flagged stale if its last commit is older than this

Env is read on tool invocation, not at server start — missing config returns a structured config error rather than crashing the server.

Tests

pip install -e .[dev]
pytest

13 tests cover: missing env → structured config error, unknown adapter rejection, full audit happy path with mocked Anthropic + Beacon + GitHub via respx, drift counting, single-project not_found path, dry-run vs apply branching, and patch validation. No network calls in CI.

License

MIT — see LICENSE.

Available Tools

3 tools

apply_drift_patchesA

Apply curated drift suggestions to Beacon (HITL).

ParametersJSON Schema

Name	Required	Description	Default
`patches`	Yes	list of patch dicts, each shaped like: { "project_id": "...", "name_hint": "...", "description": null \| "...", "outcome": null \| "...", "tech_additions": [...], "tech_removals": [...] }
`dry_run`	No	if True (default), prints intent and returns without mutation. Set False to actually delete-then-recreate each project in Beacon.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It fails to disclose that applying patches can be destructive (delete-then-recreate projects) when dry_run is false. This critical behavioral information is only in the parameter schema, not the description.

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 a single, concise sentence with no extraneous words. It is front-loaded but could benefit from including behavioral notes given the tool's complexity.

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 tool with destructive potential and an output schema, the description lacks completeness by not explaining behavior or return values. It relies on schema for details, leaving gaps in understanding for the agent.

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 baseline is 3. The description does not add meaning beyond what the schema provides for parameters. It hints at the patches being 'curated suggestions' but does not detail format or constraints.

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 it applies curated drift suggestions to Beacon, with a specific verb and resource. It distinguishes from sibling audit tools which are for detection, indicating this is for application.

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 implies usage after curation and audit, but does not explicitly mention when-not or alternatives. It provides clear context that it is for applying suggestions, not for arbitrary changes.

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

audit_portfolio_driftB

Audit every project in the portfolio against its GitHub repo.

ParametersJSON Schema

Name	Required	Description	Default
`adapter`	No	which portfolio backend to read from. "beacon" (default) or "file". The "file" adapter additionally requires DRIFT_PROJECTS_FILE.	beacon
`limit`	No	stop after N projects. Useful for fast smoke tests — the full audit on a 25-project portfolio takes ~2-3 minutes.
`model`	No	Anthropic model id. Defaults to the env DRIFT_MODEL setting (claude-sonnet-4-6 if unset).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether the audit is read-only (destructive hint), side effects, or authentication requirements. The only behavioral insight comes from the 'limit' parameter description mentioning time consumption (~2-3 minutes for 25 projects), which is insufficient.

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 a single concise sentence that quickly conveys the core purpose. It is front-loaded and efficient, with no wasted words. However, it could include additional context without becoming verbose.

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?

Despite having an output schema and three optional parameters, the description is minimal. It does not explain the overall audit process, success/failure behavior, or how it handles errors. The presence of sibling tools increases the need for more context, which is absent.

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 all parameters have detailed descriptions (e.g., adapter options, limit for smoke tests, model override). The tool description itself ('Audit every project...') adds no extra parameter meaning beyond what the schema already provides. Baseline 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 that the tool audits every project in the portfolio against its GitHub repo, which is a specific verb+resource. It distinguishes from the sibling tools 'audit_single_project' (single project) and 'apply_drift_patches' (applies patches) by focusing on all projects.

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 implies usage for a portfolio-wide audit, but does not explicitly state when to use this tool versus its siblings (e.g., 'For a single project, use audit_single_project'). No when-not or alternative guidance is provided, making it adequate but not explicit.

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

audit_single_projectA

Audit one project by id. Faster than the full audit (~10 seconds).

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	id from the portfolio backend (Beacon uses UUIDs).
`adapter`	No	which portfolio backend to read from. Default "beacon".	beacon
`model`	No	Anthropic model id override.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description reveals speed (~10 seconds) but lacks details on what the audit entails, side effects, or return behavior, leaving behavioral traits unclear.

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 two well-front-loaded sentences. Each sentence is essential, and there is no redundancy.

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?

Given the presence of an output schema and full parameter coverage, the description is minimally adequate but lacks context on the audit process and output structure, making it incomplete for a full understanding.

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 baseline is 3. The description adds no extra parameter meaning beyond the schema, which already explains project_id and adapter.

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 it audits one project by id, distinguishing it from the sibling tool 'audit_portfolio_drift' by noting it's faster, indicating a specific verb+resource+scope.

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 provides context on when to use it (faster than the full audit) and implies it's for single projects, but does not explicitly state when not to use it or name the alternative sibling tool.

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

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: full audit, single project audit, and applying patches. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (audit_portfolio_drift, audit_single_project, apply_drift_patches), making them predictable.

Tool Count5/5

With only 3 tools, the server is tightly scoped to its purpose—auditing drift and applying fixes—without unnecessary bloat or deficiency.

Completeness5/5

The tool surface covers the full lifecycle: comprehensive audit, targeted audit, and patching. No obvious gaps for the stated domain.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

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

ctx A
io.github.vanshulgoyal101
Turn a GitHub repo or docs site into agent-ready context: pack it or search it, over MCP.
RAG Systems Search Documentation Access
611
MCP Surface Lint A
io.github.DLeibner
Statically audits MCP tool surfaces for token cost, schema quality, and design issues.
Developer Tools Code Analysis
11
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29

Related MCP Servers

GitHub MCP Agent Server
Version Control Code Analysis
FMorgan-111
A
license
B
quality
B
maintenance
MCP server that exposes GitHub operations as tools for AI agents, enabling code search, issue management, and PR review.
Updated 3 months ago (2026-06-15 10:51 UTC)
12
MIT
Autonomous QA Engineer MCP
Testing & QA Tools Autonomous Agents
GolffyCoding
F
license
Not graded
quality
B
maintenance
Provides MCP tools that give LLM agents a full QA engineer workflow: scanning projects, generating deterministic test suites, executing them across browser/API/mobile, diagnosing failures, and proposing fixes that require human approval.
Updated 21 days ago (2026-08-14 07:09 UTC)
repogate
Version Control Developer Tools
JohnXu22786
A
license
Not graded
quality
B
maintenance
MCP server that wraps the GitHub REST API into tools for repo queries, issue/PR management, code review, search, and authentication, letting coding agents operate GitHub directly in conversations.
Updated 18 days ago (2026-08-17 01:41 UTC)
3
1
MIT
GitHub Dev Copilot
Version Control Developer Tools
yashwant-kumar08
F
license
Not graded
quality
C
maintenance
Enables AI agents to interact with GitHub via MCP, managing repositories, issues, PRs, and analyzing repository health through tools like list_repositories, read_issues, create_issue, comment_on_pr, and analyze_repo_health.
Updated 18 days ago (2026-08-17 16:38 UTC)

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/odanree/portfolio-drift-mcp'

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