Revit MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as ai_element_filter for querying, create_*_element for element creation by type, and delete_element for removal. However, there is some overlap between ai_element_filter, get_current_view_elements, and get_selected_elements, as all retrieve elements but with different scopes (filtered vs. view vs. selected), which could cause confusion if not carefully described. The descriptions help clarify, but the boundaries are not entirely clear-cut.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern for most tools, such as create_line_based_element, delete_element, and get_available_family_types. However, there are minor deviations: ai_element_filter uses a less standard prefix, operate_element is vague compared to others, and tag_all_walls is more specific in naming. Overall, the conventions are readable and mostly uniform, with only slight inconsistencies.
Tool Count5/5
With 13 tools, the count is well-scoped for a Revit MCP server covering element creation, querying, deletion, and operations. Each tool appears to serve a distinct function in the BIM workflow, such as creating different element types, filtering, and executing code, making the set comprehensive without being overwhelming. This aligns with typical domain-specific servers that require moderate tool counts for effective coverage.
Completeness4/5
The tool set provides strong coverage for core Revit operations, including creation (point, line, surface-based), deletion, querying (filtering, view info, selection), and specialized actions like tagging and coding. Minor gaps exist, such as lack of update or modify tools for existing elements beyond basic operations in operate_element, and no explicit tools for managing views or parameters beyond current view info. However, agents can likely work around these with the available tools, ensuring most workflows are supported.
Average 3.3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 mentions that 'Each unique parameter value gets assigned a distinct color,' which hints at output behavior, but lacks details on permissions, reversibility, view-specific effects, or error handling. For a visual mutation tool, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that efficiently convey the core functionality. It's front-loaded with the main purpose and avoids unnecessary details. However, the second sentence could be integrated more smoothly, slightly affecting flow.
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 the complexity of a visual mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., whether coloring is temporary), error cases, or output format. The schema covers parameters well, but overall context for safe and effective use is insufficient.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, only implying that 'parameter value' is used for grouping and coloring. It doesn't explain interactions between parameters (e.g., how 'customColors' overrides default behavior). Baseline 3 is appropriate given high schema coverage.
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 states the tool's purpose: 'Color elements in the current view based on a category and parameter value.' It specifies the verb ('color'), resource ('elements'), and mechanism ('based on a category and parameter value'). However, it doesn't explicitly differentiate from sibling tools like 'get_current_view_elements' or 'tag_all_walls', which might also involve visual modifications.
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 alternatives. It doesn't mention prerequisites (e.g., needing an active view), exclusions (e.g., not for 3D views), or comparisons to siblings like 'tag_all_walls' for labeling. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'creates' elements, implying a write operation, and mentions batch creation and units (mm), but fails to cover critical aspects like required permissions, whether changes are reversible, error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. It uses two sentences efficiently to cover creation, examples, batch support, parameters, and units, with no wasted words. However, it could be slightly more structured by separating usage guidelines from parameter details.
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 the tool's complexity (a mutation tool for creating Revit elements with multiple nested parameters), no annotations, and no output schema, the description is incomplete. It covers the what and some how (parameters, units) but misses behavioral context like permissions, side effects, and return values. For such a tool, more comprehensive guidance is needed.
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 schema description coverage is 100%, so the schema already documents the single parameter ('data') and its nested properties thoroughly. The description adds marginal value by listing examples of parameters (e.g., family type ID, start/end points) and specifying units (mm), but doesn't provide additional syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 states the verb ('create') and resource ('line-based elements in Revit such as walls, beams, or pipes'), making the purpose evident. It distinguishes from siblings like 'create_point_based_element' and 'create_surface_based_element' by specifying 'line-based', but doesn't explicitly contrast them. The specificity is good but could be more comparative.
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 alternatives. It mentions 'line-based elements' but doesn't explain when to choose this over 'create_point_based_element' or 'create_surface_based_element', nor does it discuss prerequisites or exclusions. Usage is implied by the resource type, but explicit context is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the ability to limit returned elements but lacks critical details: it doesn't specify what happens if no elements are selected (e.g., returns empty list or error), whether this is a read-only operation, or any performance implications. For a tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's function and parameter usage. It's front-loaded with the main purpose and avoids unnecessary details, though it could be slightly more structured by explicitly stating the tool's scope.
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 the lack of annotations and output schema, the description is incomplete for a tool that interacts with a complex system like Revit. It doesn't explain the return format (e.g., list of element IDs or full data), error conditions, or dependencies on user selection state, leaving significant gaps for an AI agent to use it correctly.
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 description adds minimal value beyond the input schema: 'You can limit the number of returned elements' implies the 'limit' parameter's purpose but doesn't provide additional semantics like default behavior if omitted or constraints. With 100% schema description coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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 states the tool's purpose: 'Get elements currently selected in Revit' specifies both the verb ('Get') and the resource ('elements currently selected in Revit'). However, it doesn't explicitly differentiate from sibling tools like 'get_current_view_elements' or 'ai_element_filter', which prevents a score of 5.
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 minimal guidance: 'You can limit the number of returned elements' hints at optional parameter usage but doesn't specify when to use this tool versus alternatives like 'get_current_view_elements' or 'ai_element_filter'. No explicit when/when-not or alternative tool references are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It lists actions but lacks critical details: it doesn't specify which actions are destructive (e.g., 'Delete permanently removes elements'), mention permission requirements, describe error handling, or explain view/state dependencies. The action descriptions in the schema help but aren't part of the tool description itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It uses 'etc.' appropriately to indicate non-exhaustive examples. However, it could be slightly more structured by grouping related actions or mentioning the tool's multi-action nature more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions with different behaviors) and lack of annotations/output schema, the description is minimally adequate. It identifies the tool's scope but misses critical context: no warning about destructive actions, no guidance on action selection, and no mention of Revit view state implications. The schema helps but doesn't replace descriptive completeness.
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 100%, providing detailed parameter documentation. The tool description adds no parameter-specific information beyond what's in the schema. It mentions action examples but doesn't elaborate on their semantics or usage. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 states the tool's purpose: 'Operate on Revit elements by performing actions such as select, selectionBox, setColor, setTransparency, delete, hide, etc.' It specifies the verb ('operate on') and resource ('Revit elements') with examples of specific actions. However, it doesn't explicitly differentiate from sibling tools like 'delete_element' or 'color_elements' that handle similar operations.
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 alternatives. It lists actions but doesn't explain when to choose this multi-action tool over specialized siblings like 'delete_element' or 'color_elements'. There's no mention of prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It describes a read operation ('Get') but lacks details on permissions, rate limits, error handling, or return format (e.g., structure of family type data). For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and briefly mentions key features. It avoids redundancy and wastes no words, though it could be slightly more structured for clarity.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'family types' entail (e.g., properties returned), how results are formatted, or any constraints like project state requirements. For a tool with three parameters and no structured output info, this leaves too much undefined.
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 100%, so the schema fully documents the three parameters. The description adds minimal value by mentioning filtering and limiting, but doesn't provide additional semantics beyond what the schema already specifies (e.g., examples of usage).
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 states the action ('Get available family types') and resource ('in the current Revit project'), making the purpose understandable. It doesn't explicitly distinguish from siblings like 'ai_element_filter' or 'get_current_view_elements', but the specific focus on family types provides some implicit differentiation.
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 description mentions filtering capabilities ('by category and family name') and limiting results, which implies usage for targeted queries. However, it doesn't specify when to use this tool versus alternatives (e.g., 'get_current_view_elements' for elements in a view) or any prerequisites, leaving usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that code is inserted into a template with access to Document and parameters, but doesn't address critical behaviors like execution safety (e.g., whether code runs in a sandbox, potential for destructive changes), authentication requirements, error handling, or performance implications. The description provides basic context but leaves significant gaps for a tool that executes arbitrary code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two clear sentences that efficiently convey the core functionality. The first sentence states the primary action, and the second provides important contextual constraints about the template structure. There's no redundant information, though it could be slightly more front-loaded with usage context.
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?
For a tool that executes arbitrary C# code in Revit with no annotations and no output schema, the description is insufficiently complete. It doesn't address safety considerations, expected return values, error conditions, or execution environment details that would be crucial for an AI agent to use this tool responsibly. The description covers basic mechanics but misses critical contextual information.
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 100%, so the schema already fully documents both parameters. The description adds minimal value beyond the schema by mentioning the template context and Execute method, but doesn't provide additional syntax examples, parameter format details, or constraints beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
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 clearly states the specific action ('Send C# code to Revit for execution'), identifies the resource (Revit), and distinguishes it from sibling tools that perform element manipulation, filtering, or creation operations. It provides a precise verb+resource combination that is unique among the available tools.
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 alternatives. It doesn't mention prerequisites (e.g., needing an active Revit session), exclusions, or compare it to sibling tools like 'operate_element' or 'ai_element_filter' that might handle different types of operations. Usage is implied only through the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states the tool deletes elements but doesn't disclose critical traits like whether deletions are permanent/undoable, permission requirements, rate limits, error handling for invalid IDs, or what happens if some IDs fail. This is inadequate for a destructive operation.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
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 this is a destructive tool with no annotations and no output schema, the description is incomplete. It lacks essential context like return values (success/failure indicators), error conditions, or behavioral nuances (e.g., batch processing effects). For a mutation tool in a modeling environment, this leaves significant gaps.
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 100%, with the parameter 'elementIds' clearly documented in the schema. The description adds no additional meaning beyond implying the IDs are for deletion, which aligns with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the specific action ('Delete') and target resource ('elements from the Revit model'), specifying the mechanism ('by their element IDs'). It distinguishes itself from sibling tools like 'operate_element' or 'get_selected_elements' by focusing exclusively on deletion.
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 alternatives. It doesn't mention prerequisites (e.g., needing valid element IDs), exclusions (e.g., not for bulk deletion of all elements), or suggest sibling tools like 'get_selected_elements' for obtaining IDs first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool retrieves information ('获取...详细信息'), implying it's a read-only operation, but doesn't confirm this or describe other traits like error handling, performance, or output format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence in Chinese that clearly states the tool's purpose and lists example attributes. It's front-loaded with the main action and resource, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is moderately complete. It specifies what information is retrieved (view details with examples) but lacks details on the return format, error cases, or how it interacts with Revit context. For a simple read operation, this is adequate but has clear gaps in behavioral context.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and a baseline score of 4 is appropriate as it doesn't introduce confusion or omissions regarding inputs.
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 states the tool's purpose: '获取 Revit 当前活动视图的详细信息' (get detailed information about Revit's current active view). It specifies the verb ('获取' - get) and resource ('当前活动视图' - current active view), and lists example attributes ('视图类型、名称、比例等属性' - view type, name, scale, etc.). However, it doesn't explicitly differentiate from sibling tools like 'get_current_view_elements', which appears to be related but focuses on elements rather than view properties.
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 alternatives. It doesn't mention any prerequisites, exclusions, or compare it to sibling tools such as 'get_current_view_elements' or 'get_available_family_types'. The context is implied (when you need view details in Revit), but there are no explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions batch creation and units (mm), which adds some behavioral context, but fails to disclose critical traits such as whether this is a mutation (likely yes, given 'create'), permission requirements, error handling, or what happens on failure. For a creation tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and key features in two sentences, with no wasted words. It efficiently covers batch creation, parameters, and units. However, it could be slightly more structured by separating usage notes from parameter details.
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 the complexity (creation tool with batch support, no output schema, and no annotations), the description is incomplete. It lacks information on return values, error conditions, or behavioral nuances like whether creation is atomic. For a tool that likely modifies a Revit model, more context is needed to guide the agent effectively.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'detailed parameters including family type ID, boundary lines, thickness, and level information', but does not provide additional semantics beyond what the schema specifies. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the verb ('create') and resource ('surface-based elements in Revit such as floors, ceilings, or roofs'), making the purpose specific. It distinguishes from siblings like 'create_line_based_element' and 'create_point_based_element' by specifying surface-based elements, which helps the agent select the correct tool.
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 description implies usage for creating surface-based elements with batch support, but does not explicitly state when to use this tool versus alternatives like 'create_line_based_element' or 'create_point_based_element'. It provides some context (e.g., batch creation) but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it describes the core action (creating tags at wall midpoints), it lacks critical information about permissions needed, whether this modifies the model permanently, error conditions, or what happens if walls already have tags. For a mutation tool with zero annotation coverage, 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 perfectly concise with two sentences that each earn their place. The first sentence establishes the core functionality, and the second adds crucial placement details. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description provides basic functionality but lacks important context about behavioral implications, error handling, and result format. The 100% schema coverage helps with parameters, but overall completeness is only adequate for the tool's complexity level.
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 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
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 clearly states the specific action ('Create tags'), target resource ('all walls in the current active view'), and placement details ('at the middle point of each wall'). It distinguishes itself from sibling tools like 'create_point_based_element' or 'get_current_view_elements' by focusing specifically on wall tagging operations.
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 description implies usage context ('current active view') but doesn't explicitly state when to use this tool versus alternatives like 'create_point_based_element' or 'operate_element'. No guidance is provided about prerequisites, view requirements, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool creates elements (implying mutation) and mentions batch creation and units, but doesn't disclose permissions needed, whether changes are reversible, error handling, or response format. It adds some context but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and efficiently covers key features in two sentences. It avoids redundancy but could be slightly more structured by separating usage context from technical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is adequate but incomplete. It covers what the tool does and basic parameters, but lacks details on permissions, error cases, return values, or integration with sibling tools like get_available_family_types.
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 100%, so the schema fully documents the single parameter 'data' and its nested properties. The description adds minimal value by mentioning batch creation and units (mm), but doesn't provide additional semantics beyond what the schema already covers. Baseline 3 is appropriate.
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 clearly states the tool creates point-based elements in Revit with specific examples (doors, windows, furniture), distinguishes it from siblings like create_line_based_element and create_surface_based_element, and specifies batch creation capability.
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 description implies usage for creating point-based elements but doesn't explicitly state when to use this versus alternatives like create_line_based_element or create_surface_based_element. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It describes the tool's intelligent querying nature and provides an example workflow, but doesn't mention performance characteristics, error conditions, authentication needs, or what happens when filters return no results. The example helps but leaves gaps in operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The example is detailed but relevant for illustrating usage. However, the second sentence could be more concise, and the example takes significant space that might be better as a separate section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex filtering tool with 1 parameter (containing 9 sub-parameters) and no output schema, the description provides good context about what the tool does but lacks information about return format, error handling, and performance limitations. The example helps but doesn't fully compensate for the absence of output documentation.
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 100%, so the schema already documents all parameters thoroughly. The description mentions filtering criteria like category, type, visibility, and spatial location, which aligns with the schema, but doesn't add significant meaning beyond what's already in the parameter descriptions. The example shows parameter usage but doesn't explain semantics further.
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 clearly states the tool's purpose as 'retrieve detailed element information from Revit projects' with specific filtering capabilities (category, type, visibility, spatial location). It distinguishes from siblings by focusing on intelligent querying for AI analysis rather than creation, deletion, or basic retrieval tools like 'get_selected_elements' or 'get_current_view_elements'.
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 provides clear context for when to use this tool: 'to answer complex user queries about Revit model elements' and gives a concrete example scenario. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools, such as when simpler retrieval tools might suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes filtering capabilities and optional parameters (includeHidden, limit) but doesn't mention performance characteristics, rate limits, authentication needs, or what happens when no elements match filters. It adequately describes the core behavior but lacks deeper operational context.
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 efficiently structured in two sentences: the first states the core purpose, the second explains key parameters. Every sentence adds value with no redundant information. It's appropriately sized and front-loaded with the main functionality.
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?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is reasonably complete. It covers the main functionality and parameters but doesn't explain return values or error conditions. For a read operation with good schema coverage, this is adequate though not exhaustive.
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 100%, so the schema already fully documents all 4 parameters. The description adds minimal value beyond the schema by mentioning the same parameters (model categories, annotation categories, includeHidden, limit) without providing additional syntax, format details, or examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the specific action ('Get elements'), target resource ('from the current active view in Revit'), and distinguishes from siblings by specifying filtering capabilities. It explicitly mentions filtering by model and annotation categories, which differentiates it from tools like 'get_selected_elements' or 'get_current_view_info'.
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 provides clear context about when to use this tool (to get elements from the current view with filtering options) but doesn't explicitly state when NOT to use it or name specific alternatives. It implies usage for filtered element retrieval but lacks explicit exclusion guidance compared to siblings like 'get_selected_elements' or 'ai_element_filter'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![revit-mcp MCP server](https://glama.ai/mcp/servers/mcp-servers-for-revit/revit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mcp-servers-for-revit/revit-mcp)

Score Badge

Copy to your README.md:

[![revit-mcp MCP server](https://glama.ai/mcp/servers/mcp-servers-for-revit/revit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mcp-servers-for-revit/revit-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mcp-servers-for-revit/revit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server