This is a solid architectural decision — wrapping audit workflows rather than raw element primitives is the right call, and the reasoning behind it is sound.
The point about element-level MCP interfaces putting the wrong work in the wrong place is well-taken. If an LLM has to enumerate elements, read properties, and apply logic across thousands of round trips just to answer "does this model follow our naming standard," you've essentially built a very expensive loop with a language model doing bookkeeping. Aggregating inside Revit and sending structured results across the WebSocket is the correct boundary to draw.
oa-aec-mcp: Revit Audit Workflows as MCP Tools
A few things worth discussing for anyone thinking about this kind of architecture:
The ExternalEvent pattern is the right call, but has a quirk worth knowing. Since all Revit API access must happen on the main thread, the ExternalEvent dispatcher is the standard mechanism — but it means your plugin is effectively fire-and-forget from the WebSocket handler's perspective. The handler raises the event and then has to wait for the result asynchronously. If you're handling concurrent requests (e.g., Claude calls two tools in quick succession), you need to be careful that your event queue and result signaling don't race. A SemaphoreSlim or a per-request TaskCompletionSource keyed to a request ID is the typical pattern for keeping this clean.
The natural-language → regex translation is the most interesting part of the naming audit tool. The fact that Claude generates the pattern before calling the tool means the coordinator never has to understand regex syntax — they describe the standard in plain English and the tool gets a machine-checkable pattern. That's a genuinely useful abstraction, and it also means the audit is reproducible: the generated regex can be logged and reused without going through Claude again.
oa-aec-mcp: Revit Audit Workflows as MCP Tools
The four-tool-per-coordination-workflow philosophy scales well. The temptation with MCP servers is to expose everything and let the LLM figure out how to compose it. The problem is that tool call count, token cost, and reasoning complexity all grow with that approach. Keeping tools at the workflow level rather than the API method level keeps the model focused on the actual question rather than orchestration overhead.
oa-aec-mcp: Revit Audit Workflows as MCP Tools
A couple of things worth considering for v0.2 beyond what's already on your list:
- Clash/interference detection summary — not full clash detection, but a read on whether there are overlapping geometry warnings in a given workset or discipline. Useful before a coordination meeting without needing Navisworks open.
- Sheet revision audit — beyond just the index, checking whether revision clouds are untagged or revisions are marked issued but clouds remain. That's a common pre-submission QA step that's tedious to do manually
