Skip to content

install: reported mcp dependency conflict on >= 10.3.0 — not reproducible from a clean env, needs reporter details #236

Description

@RichardHightower

Summary

Split out from #222, where @stevemju noted in passing:

Agent Brain: 10.2.0 (also present on main) (btw >= 10.3.0 doesn't work for me because of a mcp dependency conflicts, but that's another issue)

This is that other issue. A user is pinned to 10.2.0 and cannot upgrade, so it blocks them from picking up every fix since — including the base_url fix in #222.

Investigation so far (2026-08-30)

Could not reproduce from a clean environment. Resolutions were run with uv pip compile --python-version 3.10 (the reporter is on Python 3.10) for:

Package set Result
agent-brain-rag==10.4.0 + agent-brain-cli==10.4.0 resolves clean
the above + agent-brain-ag-mcp==10.4.0 resolves clean
agent-brain-rag/cli/ag-mcp all ==10.3.2 resolves clean

Published metadata was also checked and is correct — no path dependencies leaked into any published wheel (a real risk given agent-brain-cli/pyproject.toml carries agent-brain-ag-mcp = { path = "../agent-brain-mcp" } for local dev, which the release process swaps to a PyPI pin):

  • agent-brain-cli==10.4.0 → agent-brain-rag<11.0.0,>=10.4.0, agent-brain-uds<11.0.0,>=10.3.0
  • agent-brain-ag-mcp==10.4.0 → mcp<2.0.0,>=1.27.2, agent-brain-rag<11.0.0,>=10.4.0, agent-brain-uds<11.0.0,>=10.4.0
  • mcp itself declares requires_python >=3.10 at both 1.12.0 and 1.27.2, so there is no Python-version conflict.

Leading hypothesis

The conflict is environment-local, not a packaging defect: v10.4 raised the floor to mcp>=1.27.2 (Phase 67 needed mcp.server.auth). An environment that already holds an older mcp pinned by another MCP tool would fail to co-resolve, and pip's resolver reports that as a dependency conflict.

What's needed to close this

From the reporter:

  1. The exact install command (pip install ... / uv pip install ..., and which packages).
  2. The full resolver error text, which names the conflicting pins.
  3. pip freeze | grep -i mcp from the target environment before the upgrade.
  4. Whether installing into a fresh virtualenv succeeds.

Possible outcome

If confirmed as a pre-existing mcp pin, the fix is documentation (an install-troubleshooting note about the mcp>=1.27.2 floor from v10.4 and using a clean venv), not a metadata change.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions