Which documentation should I use as a reference?
I’m thinking of using DocDeveloper-rt as a base.
Has anyone already created and published something like this?
Are you referring to Niagara 5? As far as I know that’s the only thing where it’s available.
I’m with @Charles_Johnson, I’d wait for the official MCP. You could build your own, but it would take some work… But no point re-inventing the wheel.
I’m talking about Niagara4.
Are there currently any plans to release an official version of Niagara-MCP?
I believe they spoke about it at the summit recently and it will be introduced in N5. What’s you’re use case for the MCP? Just agentic coding?
I hadn’t been following the news about that summit—thanks.
For now, I’m thinking about agent coding.
Your instinct to start from docDeveloper is right, but docDeveloper-rt is not the part you want. On a 4.15.5.22 install that jar is 16 KB, thirteen entries, three classes plus a lexicon and a palette. It is the runtime shim for the Developer Guide, not the guide. The content lives in docDeveloper-doc: 41 MB packed, 9060 entries.
688 of those entries are HTML, and they are the Developer Guide pages you would expect: architecture, object model, component model, entity model, modules, apiInfo, plus bql, bqlExpressions and bqlExamples. But 6569 entries are bajadoc files, and those are not HTML. They are XML from Tridium’s own doclet: a class element carrying module, runtimeProfile and qualifiedName, then description, tags, extends, and the part that matters, property, action and topic elements with names, types, flags and descriptions. That corpus is 5674 type pages, 725 package indexes and 170 module indexes, holding 7023 property, 979 action and 162 topic declarations. There is a plain list of covered modules at doc bajadoc.index, 170 lines, and a JavaHelp table of contents at doc toc.xml. There is a search index too, but it is JavaHelp binary in four dat files, so index the XML yourself. If you chunk one thing, chunk the bajadoc XML, not the HTML.
There are better primary sources than documentation, though. docSource-doc ships 2669 real java files across 52 module directories, Tridium’s own source, carrying 3478 NiagaraProperty, 410 NiagaraAction and 68 NiagaraTopic annotations with their literal default values. That is precisely what a model invents, and here it is verbatim.
Every module jar carries META-INF module.xml. All 756 jars here have one, declaring moduleName, runtimeProfile, vendorVersion, dependencies with minimum versions, and a type registry: 9345 type elements mapping module colon TypeName to a Java class. That registry is the cure for hallucinated type names. Separately, 341 jars carry a lexicon, 33939 non-comment key equals value lines in total, the authoritative UI and error strings; 349 carry module.palette, 20213 entries with a type attribute, which is what is meant to be instantiated by hand rather than built in code.
One tool worth building because it cannot lie: a BQL lexer check. From the install root, run java with a classpath of bql-rt.jar, baja.jar and nre.jar against com.tridium.bql.compiler.BqlTokenizer with your query. It runs on a bare JVM with no station and prints one token per line: select, whitespace, id, dot, comma, type spec, operator, number. An unterminated string raises RuntimeCompilerException invalid.string.unterminated. Know its reach, though: it is a lexer, so it cheerfully tokenises a type spec with no module prefix. BqlParser beside it has a main but dies initialising OrdQuery without a booted Sys, and ORD parsing through javax.baja.naming.BOrd make and parse hits the same wall. Lexing is free; semantics need a station.
Which is the honest limit of the whole exercise. Static jars give you types, slots, strings, defaults and grammar. They give you nothing live: no instance tree, no point values, no histories, no alarms. Worth noting that the permission layer you would eventually want to respect is SecurityManager-based in N4, and that is the layer the move off Java 8 rewrites, so treat any station-touching design as the part to defer.