Nasdanika Models

An Ecore/Xcore metamodel for Model Context Protocol concepts: catalogs, servers and their versions, tools, resources, resource templates and prompts, the packages and remotes a server is distributed as, and the hosts and clients on the other side of the connection.

It sits on the agent model and, through it, on the Nasdanika model tower. That is the whole point: an MCP server is not just a wire protocol endpoint, it is an asset somebody owns, governs, versions, retires, threat-models, and pays for. This model treats it as such.

Motivation

MCP won the tool-integration argument. What it did not bring with it is a way to talk about servers as organizational assets.

The specification tells you how a server and a client negotiate capabilities on the wire. The official registry’s server.json tells you how to install one. Neither tells you who owns the delete_customer tool, which lifecycle stage it is in, which control it is evidence for, which threat scenarios were considered when it was approved, or which requirement it satisfies. Those answers live in wikis, spreadsheets and tickets, disconnected from the thing they describe.

Meanwhile the server definition itself is usually buried in code - Python decorators or Java annotations - where the people who must review it (security, risk, business owners, auditors) cannot meaningfully read it.

A typed model changes the workflow:

  • Metadata lives in the model, logic lives in code. Tool descriptions, schemas, annotations, examples and ownership are authored in YAML, Excel or Draw.io, validated by the metamodel - not scattered across annotations in a source tree.
  • Generated documentation is the deliverable. Every catalog, server, version, tool, resource and prompt renders to a browsable HTML site with diagrams, cross-references and search. Reviewers review that.
  • The definition is version-controlled and diffable. “What changed in this server between 1.3 and 1.4” becomes a semantic diff over model elements, not a reading of a changelog someone remembered to write.
  • It composes with everything else already modeled. Because MCP elements are tower elements, an MCP tool can appear in an architecture diagram, a threat model, a control assessment, a work item and a requirements trace - without a separate integration for each.

Core concepts

Catalog

A federated container: it owns servers and may include other catalogs. Team catalogs roll up into an org catalog; an org catalog includes curated public ones. This is the unit of curation - “the servers we allow” is a catalog, and it is a first-class documented, staged and governed model element.

Server and ServerVersion

Server is the logical identity - reverse-DNS name per the official registry convention, e.g. io.github.acme/weather - plus website and repository.

ServerVersion is the unit that actually matters operationally: a concrete published version with its protocol version, its capability set (tools, resources, resourceTemplates, prompts), its logging and completions flags, its negotiated extensions, and the packages/remotes it ships as. Capabilities hang off the version, not the server, because that is where they change.

Distribution

Package (npm, PyPI, OCI, NuGet, MCPB, …) and Remote (a hosted endpoint) mirror the registry’s server.json shape, including TransportType (STDIO, STREAMABLE_HTTP, SSE, CUSTOM), environment variables, arguments and headers. Variable carries required and secret flags - enough to generate installation documentation, and enough for a security reviewer to see at a glance what secrets a server demands.

Capabilities

Tool, Resource, ResourceTemplate and Prompt all extend Capability, which carries an optional execution Binding and a list of Examples.

  • Tool has input and output Schema (inline JSON Schema or a URI reference, classpath included) and the spec’s behavioral hints - readOnlyHint, destructiveHint, idempotentHint, openWorldHint. They are hints, not guarantees, which is precisely why they belong in a governed model where the claim can be reviewed rather than trusted.
  • Resource and ResourceTemplate cover static URIs and RFC 6570 URI templates.
  • Prompt carries arguments and a message template.
  • Example - input and output - is fuel for documentation, education and evals.

Client side

Host and Client model the other end: a host application (a desktop assistant, an IDE, an agent) containing one client per server connection, with the client capabilities the spec defines - roots, sampling, elicitation - plus the transport and the ServerVersion it connects to.

Included for completeness and for teaching, but also useful in earnest: “which hosts in this organization connect to which server versions” is a deployment question with real security consequences, and it is answerable from the model.

Bindings

Binding attaches executable behavior to a modeled capability:

Binding Dispatches to
JavaBinding a Java class/method resolved reflectively or via the capability factory
ScriptBinding inline or referenced Groovy, JavaScript, …
CapabilityBinding a capability obtained from the Nasdanika capability framework
ProxyBinding another modeled capability - composition and federation of servers

Bindings are optional. A pure documentation model has none; an interpreted model has them on every capability.

Where it sits: the tower

The Nasdanika model tower is a stack of small aspect metamodels (micro-models), each adding one dimension. MCP is a floor near the top, standing on the agent floor:

Floor What MCP elements inherit from it
nxcore documentation (Markdown, sections), provenance markers back to the authoring source, identity, and a temporal dimension - a period with a start and an end
role the undergoer/role/actor pattern: owner, accountable, responsible, security owner, risk owner, custodian - any role vocabulary you define
iam identities and access - who may invoke what
lifecycle stages and transitions: proposed → piloted → approved → deprecated → retired, with the transition rules stated rather than implied
decision-analysis criteria and alternatives - choosing between three weather servers is an MCDA problem
decision-binding who decided, what, when, and why - the decision attached to the thing it decided about
governance risks, controls, evidence, assessments, findings and waivers on any element
work workable elements and dependencies - onboarding a server, remediating a finding, migrating a protocol version
architecture MCP servers as architecture building blocks in the enterprise landscape, with relationships to the systems behind them
threat threat modeling - MCP has a genuinely interesting threat surface, and it belongs on the tools, not in a separate document
requirements requirements, and satisfaction traces from capabilities to them (not on the tower diagram yet)
ai-governance AI-specific governance vocabulary on top of the generic governance floor
agent agents, tasks, skills, LLMs - the agent model’s McpTool is the join point between an agent’s tool list and a modeled server capability

The practical consequence: none of these dimensions cost anything to add to an MCP model. You do not integrate a threat modeling tool with a server catalog - the threat and the server are elements in the same model, and the same generator renders both.

Applications

Education

MCP is taught today through tutorials and SDK READMEs. A model is a different teaching instrument: the concepts and their relationships are visible at once, in a diagram and a generated site, with examples on every capability. Host, client, server, version, transport, capability, binding - the shape of the protocol, before any code.

The client side is in the model specifically for this: a learner should see both ends of the connection.

Documentation publishing

The primary output. Point the Nasdanika CLI at a model and get a static site: every server, version and tool with its schema, examples, hints, owners, lifecycle stage and cross-references, plus generated diagrams and full-text search.

Useful in three directions:

  • Server authors publish reference documentation generated from the same source that defines the server, so it cannot drift.
  • Organizations publish an internal MCP catalog - the servers people are allowed to use, why, who to ask, and what each one costs in risk.
  • Analysts and educators publish annotated catalogs of the public ecosystem.

Enterprise MCP catalog and governance

The catalog-of-record for an organization: which servers exist, which are approved, who owns each, which lifecycle stage each version is in, which controls apply, what evidence supports the assessment, which findings are open and which are waived - with the waiver’s expiry in the model.

The information security view of an MCP estate becomes a filtered rendering of the same model, not a separate artifact assembled by hand.

Threat modeling and security review

MCP’s threat surface is specific and well documented by now: tool poisoning and rug-pull description changes, indirect prompt injection through resources, confused-deputy and token-passthrough problems at gateways, over-broad open-world tools, secrets demanded through environment variables.

With the threat floor those scenarios attach to the tool, resource or transport they apply to, and generated documentation shows a tool next to its threats, its mitigating controls and its owner. destructiveHint and readOnlyHint become claims a reviewer signs off on rather than metadata nobody reads.

AI governance and compliance

Regimes such as the EU AI Act, NIST AI RMF and ISO/IEC 42001 ask for inventories, ownership, risk assessment and change control over AI components. Tool access is exactly the boundary where an agent acts on the world, so the MCP layer is where much of that evidence naturally lives. The ai-governance floor supplies the vocabulary, the MCP model supplies the inventory, and the generator supplies the report.

Architecture and impact analysis

A modeled server version is an architecture element with relationships - to the systems it fronts, the agents that call it, the hosts that connect to it. That makes ordinary architecture questions answerable: what breaks if this server is retired, which agents depend on a protocol version we are about to drop, where a given vendor’s software is actually used.

Requirements traceability

Tools satisfy requirements, and requirements motivate tools. With the requirements floor a capability carries its trace: this tool exists because of that requirement, and here is the example that demonstrates it.

Decision analysis

Server selection is a recurring, badly documented decision. The decision-analysis and decision-binding floors record the criteria, the alternatives, the scores and the resulting decision - attached to the catalog entry, not lost in a chat thread.

Evals and test generation

Example elements are inputs and expected outputs on a capability. They document, they teach, and they generate: eval fixtures and contract tests for the server, and few-shot material for the agents that consume it.

Execution

The interpretation flavor: a runtime walks the model, registers capabilities with the MCP Java SDK, and dispatches invocations to bindings. Metadata in the model, logic in Java, Groovy or scripts. ProxyBinding composes servers - a federated or facade server assembled from the capabilities of other modeled servers.

Positioning

The MCP tooling ecosystem is crowded, but almost all of it operates at a different altitude:

  • The specification and its schema define the wire protocol and are the source of truth for it. This model does not compete with the spec - it references it. The spec describes a conversation; this describes an asset.
  • The official MCP registry and server.json define discovery and installation metadata. Package, Remote, TransportType and Variable are deliberately aligned with that shape, so server.json is an import source and an export target. What the registry does not carry is ownership, lifecycle, controls, threats or requirements - which is the reason this model exists.
  • SDKs (Java, Python, TypeScript, Spring AI, FastMCP, …) define servers in code, with metadata in decorators or annotations. That is a fine way to write one server and a poor way to review a fleet of them. Here metadata is model data and the SDK is a runtime the interpreter drives.
  • Catalogs, marketplaces and directories (Docker’s MCP catalog, Smithery, PulseMCP, Glama, cloud vendors’ API/MCP catalogs) answer “which servers exist and how do I install one”. They are discovery surfaces, and good ones. Catalog.includes is designed to reference them: curate the public ecosystem into your own governed catalog rather than replacing it.
  • Gateways and proxies enforce policy at runtime - allowlists, auth, rate limits, logging. Complementary by construction: they act at invocation time, the model is the design-time record of what the policy should be, and ProxyBinding covers the modeled-composition case.
  • Scanners and security tooling detect tool poisoning and injection patterns in live servers. Their findings have a natural home: the governance floor’s finding and assessment elements, attached to the scanned capability.
  • API description languages - OpenAPI, AsyncAPI, and for agents A2A agent cards and OASF - are the closest analogues in spirit: a typed description of an interface from which documentation and code are generated. The comparison is fair, and the difference is the tower. OpenAPI describes one API; it has no opinion about who owns it, whether it was approved, or what threatens it.

What none of the above offer, and this model does: generated documentation as the primary artifact, ownership and governance on every element, and membership in a larger modeled ecosystem - architecture, threats, requirements, work, decisions - rather than a standalone catalog entry.

The bet is simple. As MCP moves from experiments to production estates, the interesting questions stop being “how do I connect” and become “what do we have, who owns it, is it safe, and can we prove it”.

Executable model: generate or interpret

  • Generate - documentation sites, server.json registry entries, SDK scaffolding, agent-side tool declarations, eval suites, review packets.
  • Interpret - run the model directly on the JVM: a runtime registers modeled capabilities with the MCP Java SDK and dispatches to bindings.

Either way the documentation is generated from the same source as the behavior, so specification and runtime cannot drift apart.

Related Nasdanika capabilities

More context: docs.nasdanika.org and the Nasdanika Medium publication.