Skip to content

feat(mcp): add server-level instructions - #15

Merged
jlitola merged 1 commit into
mainfrom
feat/mcp-server-instructions
Apr 20, 2026
Merged

feat(mcp): add server-level instructions#15
jlitola merged 1 commit into
mainfrom
feat/mcp-server-instructions

Conversation

@jlitola

@jlitola jlitola commented Apr 20, 2026

Copy link
Copy Markdown
Contributor

Summary

  • The CLI MCP server was constructed without server-level instructions, leaving agents with no cross-tool orientation — only isolated per-tool descriptions. This PR supplies a terse, composable instructions string via the protocol's ServerOptions.instructions field.
  • A core block (always loaded) introduces the search / search_language / feedback workflow. A package-tools section is appended when the capability predicate is open, with each bullet individually gated on its backing service so half-open configurations never advertise an unregistered tool.
  • Tool registration and instruction composition now import a single isPackageToolsCapabilityOpen predicate, eliminating drift between what the server advertises and what it documents. Future package-tool PRs extend the composer with one bullet gated on the new service.

Design notes

  • Token efficiency. Content is gate-conditional, cross-tool only, and avoids duplicating argument/output guidance that lives in each tool's description. Combined gate-open footprint is ~180 tokens; gate-closed is ~95 tokens.
  • Mention↔registration invariant. mcp-instructions.test.ts asserts both directions (mentioned-implies-registered, and registered-package-tool-implies-mentioned) across six scenarios covering gate-closed, gate-open, both half-open service configurations, and the opaque-token path.
  • Stale doc fix (in-place). docs/implementation/tools.md claimed both MCP entry points called requireAuth(), which no longer matches the actual code path. Corrected alongside the new Server-instructions section since the doc was already open for the same change.

Test plan

  • bun test — 690 pass, 0 fail (was 685 before)
  • bun run typecheck — clean
  • bun run lint — no new findings (pre-existing noExplicitAny warnings on getMcpToolDefinitions untouched)
  • Codex reviewer pass with blocker-fix iteration
  • Manual: createMcpServer(deps) constructs successfully in gate-closed and gate-open deps fixtures

Supply MCP clients with rationale and tool-picking guidance via the
protocol's server-level `instructions` field. Today the MCP server
was constructed without instructions, so agents had no cross-tool
orientation — only isolated per-tool descriptions.

The composer emits a core block for the example-search workflow
unconditionally, plus a package-tools section when the capability
predicate is open. Each bullet in the package-tools section is
gated on its own backing service so half-open configurations never
advertise an unregistered tool.

Tool registration and instruction composition now import the same
`isPackageToolsCapabilityOpen` predicate, preventing drift between
what the server advertises and what it documents. The test file
asserts the mention↔registration invariant across gate-closed,
gate-open, half-open, and opaque-token scenarios.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@jlitola jlitola added the enhancement New feature or request label Apr 20, 2026
@jlitola
jlitola merged commit 65f2233 into main Apr 20, 2026
3 checks passed
jlitola added a commit that referenced this pull request Apr 20, 2026
Follow-up to the server-level `instructions` composer merged in #15:
add a one-line bullet for `package_vulnerabilities` in the
package-tools section, gated on the same `packageIntelligenceService`
presence check as `package_summary`, so the mention↔registration
invariant stays tight in every service-wiring permutation.

Test updates:
- KNOWN_TOOLS gains `package_vulnerabilities` so the invariant loop
  probes it alongside the other package tools.
- Existing half-open / gate-open / opaque-token scenarios re-verify
  the mention↔registration symmetry without new scenarios.
- Gate-closed and "both services wired" assertions gain explicit
  `package_vulnerabilities` presence / absence checks.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant