feat(mcp): project opcore nested/raw body schema into MCP tool inputSchema

coilyco-ops commented

2026-07-09 20:29:21 +00:00

Member

Summary

Follow up on coilyco-flight-deck/cli-guard nested/raw body-schema support so ward-mcp exposes truthful MCP tool schemas for complex HTTP-backed tools.

This issue is downstream of the cli-guard core work. It should wait for that upstream schema/model change to land first.

Problem

ward-mcp is currently thin and source-blind, which is good, but its advertised MCP inputSchema is only as accurate as opcore.Descriptor.InputSchema().

Today that means complex body fields appear as flat strings even though ward-mcp will forward arbitrary JSON values at runtime. The runtime path is mostly fine. The schema projection and tests/docs are not.

Requested change

Once cli-guard exposes nested/raw body schema in opcore, update ward-mcp to:

project the richer schema unchanged into MCP inputSchema
add regression tests proving object/array/raw body fields survive the projection
document the new inline authoring form and migration path from flat body "..." syntax
verify that tool calls carrying nested JSON objects continue to round-trip into opcore.Args.Body and upstream request JSON correctly

Non-goals

Do not invent a ward-mcp-only grammar if cli-guard has not landed the shared model yet.
Do not solve this with per-service special cases in chart/config.
Server-side JSON Schema validation is optional and should be considered separately if needed. It is not required to fix the current discoverability problem.

Acceptance

MCP tools/list for a spec with nested/raw body fields emits a truthful JSON Schema.
Existing simple flat-body specs remain unchanged.
Docs explain when to use flat fields vs structured fields vs raw JSON escape hatches.

Upstream dependency

This work depends on the cli-guard issue that adds nested/raw body schema support to opcore.ParseInline and the neutral schema model. Once that lands, ward-mcp can consume it without adding bespoke per-tool logic.

Filed by ward agent advisor cross-repo fan-out from coilyco-flight-deck/ward-mcp#16 (part 2 of 2, ward#424). Upstream dependency: coilyco-flight-deck/cli-guard#212.

— Codex, via ward agent

## Summary Follow up on `coilyco-flight-deck/cli-guard` nested/raw body-schema support so ward-mcp exposes truthful MCP tool schemas for complex HTTP-backed tools. This issue is **downstream** of the cli-guard core work. It should wait for that upstream schema/model change to land first. ## Problem ward-mcp is currently thin and source-blind, which is good, but its advertised MCP `inputSchema` is only as accurate as `opcore.Descriptor.InputSchema()`. Today that means complex body fields appear as flat strings even though ward-mcp will forward arbitrary JSON values at runtime. The runtime path is mostly fine. The schema projection and tests/docs are not. ## Requested change Once cli-guard exposes nested/raw body schema in `opcore`, update ward-mcp to: - project the richer schema unchanged into MCP `inputSchema` - add regression tests proving object/array/raw body fields survive the projection - document the new inline authoring form and migration path from flat `body "..."` syntax - verify that tool calls carrying nested JSON objects continue to round-trip into `opcore.Args.Body` and upstream request JSON correctly ## Non-goals - Do not invent a ward-mcp-only grammar if cli-guard has not landed the shared model yet. - Do not solve this with per-service special cases in chart/config. - Server-side JSON Schema validation is optional and should be considered separately if needed. It is not required to fix the current discoverability problem. ## Acceptance - MCP `tools/list` for a spec with nested/raw body fields emits a truthful JSON Schema. - Existing simple flat-body specs remain unchanged. - Docs explain when to use flat fields vs structured fields vs raw JSON escape hatches. ## Upstream dependency This work depends on the cli-guard issue that adds nested/raw body schema support to `opcore.ParseInline` and the neutral schema model. Once that lands, ward-mcp can consume it without adding bespoke per-tool logic. --- Filed by `ward agent advisor` cross-repo fan-out from coilyco-flight-deck/ward-mcp#16 (part 2 of 2, ward#424). Upstream dependency: coilyco-flight-deck/cli-guard#212.  — Codex, via `ward agent`

coilyco-ops referenced this issue

2026-07-09 20:29:23 +00:00

Support nested or raw JSON bodies for complex MCP tool requests #16

coilyco-ops commented

2026-07-09 22:41:14 +00:00

Author

Member

Dependency status: coilyco-flight-deck/cli-guard#212 is still open, so this downstream ward-mcp change should not start yet. The director dispatched a sibling engineer on cli-guard#212 at 2026-07-09T22:40Z; once that lands, dispatch this issue to consume the richer opcore schema.

coilyco-ops referenced this issue

2026-07-09 22:41:14 +00:00

Support nested or raw JSON bodies for complex MCP tool requests #16

coilyco-ops added the

P3

interactive

labels

2026-07-10 09:00:45 +00:00