Skip to content

feat(mcp): expose operator-approved destinations and capabilities #356

Closed

Description

@abruption

Problem

The v1.3.3 MCP server exposes only list_sessions and send_message. Callers cannot discover which operator-configured destination IDs, agent types and capabilities they are permitted to use, so they must guess or rely on out-of-band instructions.

Proposed scope

Add an explicit destination/capability discovery tool using the existing operator policy as its authority. The API name and schema are design candidates, not published commands. Report only configured destination aliases, allowed agent types and allowed actions, plus explicit support/limitation metadata that can be derived without contacting an agent.

Acceptance criteria

  • Inspect only the effective operator-supplied policy. Do not invoke native CLIs, SSH, network discovery, model calls or message submission to enumerate configured destinations.
  • Default policy still permits only local listing. Enumerating a policy does not grant send, wake, diagnostic or new route access.
  • Return a bounded, versioned, machine-readable result with explicit unsupported/unknown distinctions.
  • Use a deliberately small output allowlist. Do not expose raw home paths, SSH identity/config contents, tokens, message bodies or other secrets by default.
  • Treat aliases and descriptions as untrusted data; returned metadata is not caller authentication, destination readiness, permission approval, submission evidence or ACK.
  • Add installed stdio/schema and policy fixtures for explicit/default policies, malformed/unknown values, allowlists and non-reflection. Preserve existing structured/text result and error behavior.

Boundaries and dependencies

Use as the foundation for separate MCP preflight and diagnostic work. Do not add arbitrary host/path/command overrides, policy mutation, background scans or automatic retry. Preserve stdio transport and independent host approvals.

Source baseline: v1.3.3 MCP adapter and MCP guide.

Planning

Proposed v1.4.0 candidate, priority P2. No committed release date. Issue registration is not implementation, live-test, merge, release, installation or operational approval.

MCP extension sequence

First candidate slice: this destination contract, then #357 structured preflight and #358 bounded diagnostics. The owner added #359 presets as a separate fourth v1.4.0 candidate slice on 2026-11-02. #360 scoped handoff observation remains Long-term. This supersedes the original three-item release plan.

Activity

  1. added this to the v1.4.0 milestone on Nov 2, 2026
  2. self-assigned this
    on Nov 2, 2026
  3. added
    priority:P2Planned reliability, acceptance or feature work; priority does not authorize implementation.
    on Nov 2, 2026
  4. abruption commented on Nov 2, 2026

    @abruption
    OwnerAuthor

    Implementation prepared in PR #361 (head ad34fcd). Owner-authorized 2026-11-02 sequence is #356 → #357/#358 → #359 in the v1.4.0 candidate, superseding the original note that deferred #359. #360 remains Long-term. Paired independent CLI review, translation QA and current PR CI are recorded in the PR; this is not merge/publication/native acceptance.

  5. abruption commented on Nov 2, 2026

    @abruption
    OwnerAuthor

    Verified on 2026-11-03 against published v1.4.0, source 476c67e636ef02cb93797dd2f42252dfe577625f. The exact main CI passed all 37 jobs (including the 12 Mac/Linux MCP SDK/version cells), and publication/PyPI verification passed all 6 jobs. This completion audit is a source/test/contract review, not a new native/SSH/model/ACK experiment.

    Implementation: PR #361, merge 444959c08acadc85ec48722c03354a3905fac174.

    The shipped policy-only destination inventory meets the bounded projection, unchanged default/action permissions, non-reflection and installed stdio criteria. It projects configured policy entries; it does not authenticate the caller, prove readiness or grant actions.

    Closing as completed for the shipped scoped contract; Long-term native identity/storage, handoff and integration research remain separate.

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

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestpriority:P2Planned reliability, acceptance or feature work; priority does not authorize implementation.

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions