Skip to main content
Glama
revitbridge

revit-bridge

by revitbridge
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

revit-bridge

Intent bridge between designers and AI for Autodesk Revit: an MCP server that executes code in a running Revit, keeps a library of reusable capability packs, and refuses to run anything the designer has not confirmed.

The package contains no model SDK, no vector store and no web framework. Your MCP host (Claude Desktop, Claude Code, any MCP client) brings the model; the revit-bridge-addin inside Revit executes the code.

Install

Prerequisites: Python 3.11+ with uv (for uvx), Revit 2026 with the add-in installed and its local TCP listener on (default 127.0.0.1:18080).

Claude Desktop — claude_desktop_config.json:

{
  "mcpServers": {
    "revit-bridge": {
      "command": "uvx",
      "args": ["revit-bridge"]
    }
  }
}

Claude Code - the plugin (skill + MCP server + confirmation hook, recommended):

/plugin marketplace add revitbridge/revit-bridge
/plugin install revit-bridge@revit-bridge

The plugin's .mcp.json starts the server with uvx; its hooks/hooks.json denies execute_code / run_tool calls that carry no confirmation token (uv run executes plugin/hooks/spec_gate.py, so uv must be on PATH). The skill is also installable on its own with npx skills add revitbridge/revit-bridge.

MCP server only, without the skill and hook:

claude mcp add revit-bridge -- uvx revit-bridge

Any MCP client — run uvx revit-bridge as a stdio server. Pass connection settings through environment variables (see Configure), for example in the env block of the host's server entry.

Your own host — the same flow is a package API: revit_bridge.execution (run_pack, run_code, revalidate) with your own ToolStore, Gate, Ledger and Revit client, plus revit_bridge.host_instructions() for a host whose interface does the confirmation.

From a checkout: uv sync then uv run revit-bridge.

Develop a standalone C# add-in — the revit-addin-dev skill in plugin/skills/ continues an existing project or creates a minimal command project for Revit 2024, 2025, 2026, or 2027, including the 2025.5/2026.5 .NET 10 updates (2027 is .NET 10 only). Select the exact installed release, not just its year. It uses bridge tools for relevant model context and prototype checks, then delivers a DLL that runs independently of the bridge. Coding and building can proceed without a live connection.

Start from a brief — the revit-task-brief skill rewrites a designer's one-sentence request ("I pick two crossing pipes and the first one gets jogged over the other") into a testable brief before any code: numbered behaviour, inputs with units and defaults, cancel and failure rules, the facts that must be read from the open project, deliverables, verification and the decisions taken. The coding skills then implement the brief.

From a checkout, load the skills with claude --plugin-dir ./plugin, or copy the complete plugin/skills/revit-addin-dev folder into your agent's skills directory. Example request: "Use revit-addin-dev to continue my C# plugin, inspect the selected walls through revit-bridge where needed, and build an independent command." The bundled scripts/new_addin.py --help describes the starter generator; it does not install or launch the add-in.

Related MCP server: Civil3D MCP Server

Use

  1. Start Revit, open a project and make sure the add-in is listening.

  2. Check the connection:

    uvx revit-bridge check

    Prints host, port, whether a token is set, the open document's title (document, or document_error when the add-in answered but could not read it) and "status": "connected", plus capability (supported when the add-in answers get_bridge_capabilities, unsupported for an older add-in, unknown with the reason otherwise) and environment (Revit version and runtime); the exit code is 0 when the add-in answered, 1 otherwise.

  3. In your host, the flow is snapshot → questions → confirmation → execution → validation:

    • get_project_snapshot — what the model contains (units, levels, grids, family types, selection, …); query(kind, args) answers single read-only questions (levels, grids, family_types, elements, selection, view_elements, units, counts). Neither needs confirmation.

    • list_tools — the capability packs (eight built-ins such as create_wall, create_structural_column, query_levels, plus your own); missing_params(tool, known) — the questions still open, with the real options, who can answer each (kind) and the steps it holds up (blocks); get_tool_choices(name) — levels, types or elements for a pack's dynamic parameters.

    • reconcile(spec, snapshot) — a draft TaskSpec against the model: values that do not exist, missing parameters, readings to confirm (units, "on F2"), a stale snapshot.

    • check_code(code, parameters) — compiles C# for execute_code in Revit without running it (no token): diagnostics with lines in your code, hints, and guidance (the lessons for those errors, or pointers once it compiles); checked: false when the add-in cannot (an older add-in).

    • get_guidance(stage=...) — lessons for writing Revit code (the snippet contract, units, API pitfalls), chosen by stage, API symbols, OST_* categories, compiler errors and run-time exceptions; read-only, no token.

    • confirm_spec(spec) with the TaskSpec the designer confirmed, then run_tool(name, params, token) with exactly the confirmed values.

    • plan_verification(template, params) / verify_execution(evidence_id, verification_id) — for execute_code: a read-back check (created_ids, count_delta, param_equals) planned before confirming, run after; no token.

    execute_code takes arbitrary C# for tasks no pack covers. The code runs inside Revit with document in scope and a transaction already open; end it with return <object>;. When it throws in Revit, the reply's hint names the get_guidance(stage="fix", exceptions=[...]) call for that exception. solidify_tool saves code that worked as a new pack.

    A pack's validator (created_ids, count_delta or param_equals) asserts the outcome after the run: success is true only when Revit succeeded and the assertion held, and every execution leaves a line in the evidence ledger (evidence, validate(evidence_id)).

Devices and the dialog in Revit. A host that reaches Revit over the network (the web demo) pairs each add-in installation once: DeviceStore.create_pairing() hands out a XXXX-XXXX code that is valid for ten minutes, the add-in redeems it with DeviceStore.redeem(code) and keeps the device token it gets back, and the browser that asked for the pairing keeps a browser key. Only sha256 digests of the code, the token and the key are stored (<data dir>/auth/devices.json); verify_device, verify_browser and revoke are how a host authorises a request afterwards. Each confirmation and each ledger line then carries the scope it belongs to

  • the device_id, or local for the add-in on this machine - and a token confirmed for one device cannot be redeemed on another. Independently of any client setting, execute_code asks the designer once more in Revit: the request carries the confirmed spec card, the add-in shows it with Yes/No and waits up to three minutes, and a No comes back as error: "declined_on_device" (the token is spent and the run is in the ledger). run_tool runs capability packs without that dialog.

Confirmation gate. execute_code and run_tool return confirmation_required without a token. A token comes only from confirm_spec(spec): the TaskSpec lists every parameter with its value, source and evidence; the server validates it and issues a one-time token bound to exactly that tool and those parameters (or that code). Running anything else with it, reusing it, or using it after 10 minutes fails with confirmation_invalid. missing_params and reconcile help build the spec. Hosts that run their own confirmation flow can set REVIT_BRIDGE_ALLOW_UNCONFIRMED=1.

Resources: revit://stats, revit://tools/{name}, revit://evidence/recent, revit://connection-status, revit://guidance/index.

Guidance layers and CLI. get_guidance and check_code read the packaged lessons (framework) and up to three directories laid out the same way: company (REVIT_BRIDGE_GUIDANCE_COMPANY), project (REVIT_BRIDGE_GUIDANCE_PROJECT) and personal (<data dir>/guidance). A higher layer replaces a lesson of the same id, except a company lesson with enforced: true; a layer that fails validation is left out with a layer_invalid warning. uvx revit-bridge guidance check validates them (exit 1 on a problem), guidance index [DIR] [--check] rebuilds the lesson indexes and the revit-core skill export, and guidance explain --stage fix --errors CS1061 --symbols Wall LocationCurve prints what would be recommended, and why.

The plugin ships an eval suite (plugin/evals/, the three baseline tasks and two second-turn cases, with mocks of the MCP server). Run it by hand from plugin/ with claude plugin eval . (on Windows in a UTF-8 console: chcp 65001 first, or the Chinese prompts reach the model garbled); it is not part of CI.

Pair with revit-api-docs

revit-api-docs is an optional second server: search_revit_api looks API names up in the Revit 2026 API reference, and check_code hints point at it. The plugin does not start it: add it with claude mcp add revit-api-docs -- uvx revit-api-docs, or in one config:

{"mcpServers": {"revit-bridge": {"command": "uvx", "args": ["revit-bridge"]},
                "revit-api-docs": {"command": "uvx", "args": ["revit-api-docs"]}}}

Its first run downloads the data set v1.1-data (267 MB; uvx revit-api-docs download fetches it ahead of time): the Revit 2026 API reference, including constructors such as new XYZ(x, y, z) and interface members. From revit-api-docs 0.3.0 on, TYPESAFE_API_KEY alone turns on Jev reranking; Cohere is optional. For multi-step task requests (several steps in one sentence) also set an embedding key, REVIT_API_DOCS_EMBEDDING_API_KEY (OpenRouter, model openai/text-embedding-3-large), to fuse vector search with keyword search. On 223 English test queries the fused nDCG@5 was 0.647 against 0.557 for keyword search alone, both without reranking, and 0.842 with Jev. Each query makes one more embedding call (about 0.9 s, negligible cost); every setting is in its README.

Configure

Variable

Default

Meaning

REVIT_BRIDGE_HOST

127.0.0.1

Host where the add-in listens

REVIT_BRIDGE_PORT

18080

TCP port of the add-in

REVIT_BRIDGE_TOKEN

(unset)

Pre-shared token, sent with every request when the add-in has one configured

REVIT_BRIDGE_TIMEOUT

60

Seconds to wait for a command to finish

REVIT_BRIDGE_ALLOW_UNCONFIRMED

(unset)

1 lifts the confirmation-token gate (host-internal flows only)

REVIT_BRIDGE_CONFIRM_TTL

600

Seconds a confirmation token stays valid

REVIT_BRIDGE_DATA_DIR

%LOCALAPPDATA%\revit-bridge (Windows), ~/.local/share/revit-bridge (else)

Per-user data: solidified packs, usage.json, the evidence ledger, auth/devices.json, verifications/ (read-back plans)

REVIT_BRIDGE_CAPABILITIES_DIR

<data dir>/capabilities

User pack directory; the packs shipped in the wheel stay visible, a user pack of the same name replaces one

REVIT_BRIDGE_EVIDENCE_DIR

<data dir>/evidence

Evidence ledger (<YYYY-MM>.jsonl) and pending confirmations

REVIT_BRIDGE_GUIDANCE_COMPANY

(unset)

Company guidance layer: a directory laid out like plugin/guidance; its lessons replace packaged ones of the same id

REVIT_BRIDGE_GUIDANCE_PROJECT

(unset)

Project guidance layer, above the company one; the personal layer is <data dir>/guidance when it exists

Development:

uv sync
uv run pytest
uv build
uvx --from . revit-bridge check
uv run revit-bridge guidance check plugin/guidance
uv run revit-bridge guidance index plugin/guidance --check

License: MIT. Issues and discussion: https://github.com/revitbridge/revit-bridge/issues.

Available Tools

5 tools
execute_codeA
Destructive

Send C# code to Revit for execution over the local TCP socket. Refused unless spec_confirmed=true (the designer confirmed the task spec). Returns execution result or error message.

NameRequiredDescriptionDefault
codeYes
parametersNo
spec_confirmedNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry readOnlyHint=false and destructiveHint=true, and the description is consistent with them. It adds value beyond the annotations by disclosing the spec_confirmed refusal behavior and the return contract (execution result or error message), which the annotations do not convey. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: the core purpose is front-loaded, followed by the critical gating condition, then the return behavior. Zero fluff or repetition of schema/annotation content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists (covering the return contract) and annotations cover the safety profile (destructive, not read-only), so the description needn't repeat those. It covers purpose and the critical gate. The one notable gap is the parameters array semantics, which remain undefined in both schema and description; however, a correct basic invocation is still achievable with just code and spec_confirmed=true.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains spec_confirmed explicitly ('must be true or the tool refuses') and implies the code parameter (the C# code being sent), but it never clarifies the free-form parameters array — what it contains, whether it maps to method arguments, or its relationship to the code. This is only partial compensation for the absent schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is highly specific: 'Send C# code to Revit for execution over the local TCP socket' names the verb, the resource, and the transport mechanism. This makes it easy to distinguish from siblings like list_tools, get_tool_choices, and run_tool without looking at their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear invocation context by disclosing the refusal gate: 'Refused unless spec_confirmed=true'. This tells the agent when the call will fail and what precondition must be met. However, it does not explicitly contrast with alternatives such as run_tool or say when NOT to use it beyond the gate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_tool_choicesA
Read-only

Query Revit for dynamic parameter choices of a solidified tool. Call this BEFORE run_tool to discover available levels, family types, etc. Returns {param_name: [{label, value}, ...]} for parameters that need selection.

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already signals a non-mutating operation, and the description adds useful behavioral detail beyond that: it returns parameter-name-to-options mapping and targets only parameters that need selection. No side effects, permissions, or error behavior are described, but for a read-only query tool with an output schema this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with no filler: the purpose is front-loaded, the sequencing guidance is immediate, and the return format is stated exactly. Every sentence contributes a distinct, useful fact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one simple parameter, an output schema, and read-only annotations, the description covers the essential workflow: discover choices before running. The only notable gap is the imprecise parameter meaning, and there is no mention of what happens if the tool is not yet solidified. These are minor given the low complexity and existing output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden of explaining the 'name' parameter. It says 'of a solidified tool' but never explicitly states that name is the solidified tool's name; this is only implied. A clear mapping such as 'name = the name of the solidified tool' would have compensated for the empty schema, and its absence makes the parameter meaning ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pairing ('Query Revit for dynamic parameter choices of a solidified tool') and adds the return shape, so an agent knows exactly what to expect. It also differentiates the tool from siblings by positioning it as the discovery step before run_tool, making its role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: 'Call this BEFORE run_tool to discover available levels, family types, etc.' This is clear context for the primary use case. It does not enumerate when-not-to-use cases or name multiple alternatives, but the run_tool reference is sufficient for typical agent selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_toolsA
Read-only

List all solidified tools available for execution.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already communicates that this is a safe read operation, and the description adds the scope that only 'solidified' tools are listed. It does not describe any further behavioral traits such as ordering, filtering, or output limitations, but for a simple list tool with an output schema this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no filler or redundant wording. It conveys the core purpose efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with an output schema, the description provides sufficient context for an agent to invoke it correctly. The only minor gap is that it does not clarify how this listing differs from the sibling get_tool_choices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema is already complete with 100% coverage. The description reinforces that the tool lists all available tools without requiring inputs, which is consistent with the empty parameter set.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action ('List') and the resource ('all solidified tools available for execution'), making the tool's purpose easy to grasp. However, it does not explicitly distinguish itself from the sibling get_tool_choices, which could plausibly serve a similar listing role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus siblings like run_tool or get_tool_choices. There is no mention of the appropriate context, prerequisites, or why this tool should be selected over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_toolA
Destructive

Execute a solidified tool by name with given parameters. IMPORTANT: Call get_tool_choices first for parameters with choices_from / source: query:*. Refused unless spec_confirmed=true (the designer confirmed the task spec). params: JSON object of parameter values, e.g. {"level_name": "L1", "height": 3000}

NameRequiredDescriptionDefault
nameYes
paramsNo{}
spec_confirmedNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses a refusal gate (spec_confirmed=true) and a required preceding call for dynamic params. The destructiveHint annotation already covers destructiveness, and the description adds concrete behavioral constraints without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences; the main verb+object, the most important warning, and a concrete parameter example are packed with no filler. The critical prerequisites are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential invocation path: call get_tool_choices for generated params, set spec_confirmed=true, and supply params JSON. With an output schema present and annotations covering safety, remaining gaps such as where names come from are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The example of params as a JSON object and spec_confirmed=true adds meaning to the otherwise bare schema, which has 0% coverage. However, it calls params a 'JSON object' while the schema declares a string type, which can mislead an agent into passing an object instead of a JSON-encoded string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States 'Execute a solidified tool by name with given parameters.' This names a specific verb and target and clearly differentiates from siblings like solidify_tool (creation), list_tools, and get_tool_choices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit prerequisites: call get_tool_choices first for parameters with choices_from / source: query:*, and notes the tool is refused unless spec_confirmed=true. It does not explicitly compare with execute_code or list_tools, but the required conditions are clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

solidify_toolB

Save a successful code execution as a reusable named tool. parameters: JSON array of {name, type, description, source?, default?, choices_from?} tags: comma-separated tags

NameRequiredDescriptionDefault
codeYes
nameYes
tagsNo
parametersNo[]
descriptionNo
source_queryNo

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the outcome (saving a reusable named tool) but does not disclose side effects, overwrite behavior, persistence, what counts as 'successful,' or how the tool relates to prior execution state. For a mutation-like tool, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, stating the core purpose in the first sentence and following with useful parameter format hints. There is no filler or redundant restating of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no annotations, and an output schema that covers return values, the description still leaves important gaps: what 'source_query' means, how a successful code execution is identified, and any prerequisites. The agent has enough to attempt a call, but not to confidently ensure correct invocation. An output schema does not excuse missing parameter context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaningful format details for 'parameters' ('JSON array of {name, type, description, source?, default?, choices_from?}') and 'tags' ('comma-separated tags'), which the schema does not provide. However, it leaves 'source_query' and the top-level 'description' field unexplained, and code/name are only self-evident from their names. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Save a successful code execution as a reusable named tool.' This clearly distinguishes it from sibling tools like execute_code (executes), run_tool (runs a tool), and list_tools (lists tools). An agent can immediately understand what this tool accomplishes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'successful code execution' implies the tool should be used after code has been executed successfully, providing some contextual guidance. However, the description does not explicitly say when to use this tool over alternatives, nor does it mention exclusions or prerequisites. Usage context is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedexecute_code
    • First observedget_tool_choices
    • First observedlist_tools
    • First observedrun_tool
    • First observedsolidify_tool
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 5 tools

Disambiguation4/5

Most tools have clearly distinct roles: execute_code runs raw C#, run_tool runs saved tools, solidify_tool creates them, and list_tools/get_tool_choices support discovery. However, execute_code and run_tool both perform execution, which could cause an agent to misselect when only one is appropriate.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: execute_code, solidify_tool, list_tools, get_tool_choices, run_tool. The naming is predictable and makes the surface easy to navigate.

Tool Count5/5

Five tools is well-scoped for a Revit bridge: execute raw code, solidify it, list solidified tools, query parameter choices, and run a solidified tool. Each tool earns its place with no unnecessary redundancy.

Completeness3/5

The set covers creating, listing, querying, and running solidified tools, but lacks update and delete operations for those tools. There is also no way to view a single tool's details, leaving the lifecycle partially incomplete.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers