Skip to content

Schema view doesn't expose nested object sub-fields (e.g. Open Brain metadata.share_candidate) #55

Description

@rodaddy

Problem

mcp2cli schema <server>.<tool> and the --params help render the flat MCP inputSchema from tools/list. When a tool has a nested object parameter, the sub-fields are opaque — a CLI caller can't discover them.

Concrete case (Open Brain, contract 2026-06-19.memory-tools.v5, live at http://10.71.1.21:3100/mcp):

$ mcp2cli schema open-brain.append_session_event
  "metadata": { "description": "Arbitrary JSON metadata; max 50 keys, max 100KB total" }   # opaque

But OB's metadata now carries a recognized nested field, share_candidate (boolean), which nominates an event for promotion to the shared-kb namespace — with rich usage help. A CLI caller (Rico/Claude via mcp2cli) currently has no way to discover it from mcp2cli schema; they'd have to read the OB source. The flat tool list hides it.

This is the bridge half of the new OB memory-promotion feature (open-brain #161/#172). The agents (rtech-hermes) consume OB directly over HTTP, but mcp2cli is the path Rico/Claude use, and right now that path can't see or correctly form a share_candidate nomination.

Repro

mcp2cli open-brain --help                       # append_session_event + promote_shared present (good — live discovery works)
mcp2cli schema open-brain.append_session_event  # metadata shown as opaque; no share_candidate sub-field

Proposed approaches (maintainer's call)

A. Recurse nested object fields (source-agnostic). When an inputSchema property is type: object with nested properties (standard JSON Schema) — or OB's contract dialect fields — render the sub-fields with their description/type/required. Works for any MCP server, not just OB. This is the minimal, general fix.

B. Prefer get_contract for servers that publish it (OB-aware). OB exposes get_contract with a richer per-field/per-tool help manifest (tool_contracts.append_session_event.input_schema.metadata.fields.share_candidate.description, etc.). mcp2cli could, for servers advertising that capability, render schema/help from the contract instead of the flat tools/list. Richest help, but couples mcp2cli to the OB contract dialect (fields vs properties).

A handles the general case; B gives the best help for OB specifically. They're not exclusive — A could read fields OR properties, getting most of B's benefit generically.

Acceptance

  • mcp2cli schema open-brain.append_session_event shows metadata.share_candidate (boolean) with its help text.
  • A --params '{"...","metadata":{"share_candidate":true}}' call round-trips correctly (already works at the transport layer; this is purely the discoverability/help gap).
  • No regression for flat tools (e.g. promote_shared renders unchanged — verified it already shows table/id/reason/dry_run correctly).

Context

  • Open Brain server source of truth: contract tool_contracts in open-brain repo src/contract-schemas.ts; nested help lives under metadata.fields.
  • Live verification done 2026-06-19: promote_shared and append_session_event ARE discovered live (no static cache to update) — the only gap is nested-field rendering.

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions