#3219·context7

[Feature]: Make proactive MCP instructions configurable and clarify reuse of resolved library IDs

Author: ipad4Created Sep 20, 2026Updated Sep 26, 2026

Problem Description

Context7 is useful as a documentation source, but its MCP instructions also prescribe a broad retrieval policy. I use it as a personal, globally configured MCP server while working in repositories shared with other developers, whose tool setups may differ.

The current server instructions tell the agent to fetch documentation across library, framework, SDK, API, CLI, and cloud-service questions, including when it believes it already knows the answer. The existing exclusions for refactoring, business-logic debugging, code review, and general programming concepts are helpful. However, there is no clear exception for a relevant task where authoritative, version-appropriate evidence is already available in the current context.

Model confidence alone should not replace documentation. Having sufficient source code, type definitions, official documentation, or a still-applicable earlier query result is a different case.

The resolve-library-id description and query-docs description also require resolution before querying, with an explicit exception for user-provided IDs. Clarifying that a previously resolved, still-valid ID can be reused would remove ambiguity about whether resolution must be repeated on a follow-up question.

Proposed Solution

  1. Make proactive routing instructions configurable at the MCP integration level. Provide a neutral or on-demand option that retains the tools and their usage requirements while letting the host agent decide whether additional documentation is needed. The current proactive behavior could remain available for users who want it. Apply the selected policy consistently to server instructions and tool descriptions.
  2. Explicitly permit reuse of valid evidence. Allow an ID already resolved in the current task to be reused when the library and requested version still match. Re-resolve when the identity/version is uncertain, changes, or the ID stops working. Likewise, do not encourage repeating a documentation query when its result still answers the question and meets the task's freshness requirements.

Suggested acceptance scenarios, rather than claims of reproduced failures:

  • With sufficient version-appropriate evidence already in context, the neutral option does not instruct the agent to perform another lookup solely because a library is mentioned.
  • A follow-up about the same library/version can use the previously resolved ID directly.
  • A missing or uncertain ID, a version change, or an explicit request for fresh documentation still leads to the appropriate lookup.

Alternatives Considered

  • Adding counter-instructions to personal agent files introduces competing guidance. Adding tool-specific exceptions to shared project AGENTS.md files would also make a team's instructions depend on individual developers' global tool choices. This preference should be configurable at the individual MCP integration boundary.
  • Maintaining a local fork or description-rewriting proxy adds upkeep for a small policy difference.
  • Disabling the MCP server or switching interfaces gives up the existing integration without addressing its instruction design.

Priority

Would improve my workflow.

Additional Context

  • Local integration reviewed: Codex Desktop with @upstash/context7-mcp 4.1.1 over stdio.
  • Source references above are pinned to commit 12db78ea043954de047277960fda7e1d28f1d420.
  • Related: #2287 requested built-in proactive triggering. This proposal preserves that use case while giving hosts with their own retrieval policies an alternative.
  • This is an instruction/configurability enhancement based on the published descriptions. I have not collected a controlled before/after invocation trace or measured a latency/token regression, and am not reporting a confirmed API malfunction.