Proposal: an MCP server for Ossie (and where it should live)

[Ashfaqbs]

Proposal

I'd like a maintainer steer before building anything: does an MCP server for Ossie (and, downstream of that, a thin agent built on it) fit this project, and if so, where should it live?

What it would do

An MCP server exposing Ossie semantic models as tools an AI agent can call directly, instead of an agent reading/writing raw YAML by hand or guessing at the schema. A rough first cut:

• validate_model - validate a semantic model document against the Ossie schema (wraps validation/), returning structured errors an agent can act on instead of parsing CLI output.
• list_vendors / describe_dialect - surface the registered vendor names and Dialect enum values from core-spec/spec.yaml so an agent doesn't have to guess which converter or expression dialect exists.
• convert_model - invoke a given converter (dbt, Salesforce, Power BI, etc.) in either direction, returning the converted document plus any warnings the converter logged.
• query_model - answer structural questions about a loaded model (list datasets/metrics/relationships, find a metric's dependencies, find custom_extensions for a given vendor) without the agent having to walk the YAML itself.

Why this seems worth asking about

Discussion #374 (downstream agent field reports) already notes that coding/autonomous agents are a real, heavy consumer of this spec, and that that usage produces its own friction (issue-sprawl from agents guessing at the schema). An MCP server is a fairly direct answer to "give agents a correct, narrow interface instead of letting them freelance against raw YAML" - it would reduce exactly the kind of fragmented, context-free issues that discussion is trying to get ahead of.

Where should this live?

I saw #453 proposes that new converters go to separate repositories (apache/ossie-converters, or coordinate on the dev mailing list) rather than the main repo. An MCP server isn't a converter, but it's the same shape of question - new tooling built on top of the spec rather than the spec itself. I'd rather ask than assume: should this go in a new repo under the Ossie project (e.g. alongside ossie-converters), as a community project referenced from the README, or is this out of scope for the project entirely?

Happy to scope a first PR to just validate_model and list_vendors/describe_dialect against the Python validation tooling already in validation/ if there's interest, once there's a steer on where it should live.

[jbonofre]

I'm not sure we need MCP server at all in Ossie. That could be something catalogs can do.

I would rather not consider MCP service directly in Ossie for now (I don't see the value).

[jakub-moravec]

@Ashfaqbs can you think of any tools that would have to be built out for this? Isn't it sufficient to define skills (potentially as part of Ossie), and then offload the tools/MCP support to vendors?

[Ashfaqbs]

@jakub-moravec good question, and I think it cuts to the actual disagreement with @jbonofre too, so let me try to answer both at once.

A "skill" (in the sense discussion #374 means it, and in the sense most agent frameworks use the word) is advisory: it's text that tells an agent how to think about a problem - "here's the shape of an Ossie model, here's what a metric/relationship looks like, here's how custom_extensions work per vendor." It doesn't give the agent a way to check whether what it produced is actually valid. With only a skill, the agent still free-types YAML from memory of the schema, and discussion #374's issue-sprawl problem - agents guessing at the schema and filing issues when they guessed wrong - doesn't go away. A skill changes how good the guess is; it doesn't remove the guessing.

validate_model specifically isn't new tooling in the sense of "a thing Ossie has to build and maintain" - it's a thin MCP wrapper around the CLI that already exists in validation/. The only thing it adds is making that existing validator callable as a structured round-trip instead of a shell-out-and-parse-stdout step, which is what lets an agent self-correct in a loop rather than producing one guess and stopping. That's the piece I don't think "define skills, offload the rest to vendors" covers: the validator is the project's single source of truth on what's a valid model, and if every vendor wraps it separately, you get N slightly different wrappers around the same schema instead of one.

list_vendors/describe_dialect are in the same category - they just read core-spec/spec.yaml's existing enum/registry, so there's no new logic to maintain, only a narrower interface to the data that's already there.

Where I think @jbonofre's skepticism is fair: convert_model and query_model are a different story - those would be real new surface area, and I'm not asking for those to be greenlit here. If there's interest in testing whether this is worth the maintenance cost at all, I'd rather scope a first PR to just validate_model (zero new logic, wraps validation/ as-is) and see if it actually reduces the issue-sprawl discussion #374 describes, before considering the rest.

[jakub-moravec]

@Ashfaqbs The distinction of responsibilities for validate (Ossie) and convert/query (vendors) makes a lot of sense to me.