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, but there is some overlap between ai_element_filter, get_current_view_elements, and get_selected_elements in retrieving elements, which could cause confusion. However, their specific focuses (intelligent querying, current view, selected elements) help differentiate them. Other tools like create_line_based_element and create_surface_based_element are clearly distinct based on element type.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., create_line_based_element, delete_element, get_available_family_types) with minor deviations. One tool, operate_element, uses a vague verb 'operate' instead of something more specific like 'modify', and send_code_to_revit is slightly less structured, but overall the pattern is clear and readable.
Tool Count5/5
With 13 tools, this is well-scoped for a Revit MCP server covering element creation, querying, modification, and execution. Each tool serves a specific function in the domain, such as creating different element types or retrieving element information, without being overly bloated or sparse.
Completeness4/5
The tool set provides good coverage for core Revit operations, including creation (point, line, surface-based), deletion, querying, and modification. Minor gaps exist, such as no explicit tool for updating element parameters beyond color or transparency, and the domain could benefit from more specialized tools for tasks like scheduling or exporting, but agents can work around these with existing tools like operate_element or send_code_to_revit.
Average 3.2/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It doesn't disclose whether this is a temporary visualization or permanent change, if it requires specific permissions, what happens on view changes, or any performance/rate limitations for large element sets.
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?
Two concise sentences that efficiently convey the core functionality. The first sentence states the action and key parameters, while the second explains the coloring logic. No wasted words or redundant information.
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 4-parameter visualization tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'coloring elements' means in practice (overrides? filters?), what the user sees as a result, or important constraints like which views support this operation.
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 complete parameter documentation. The description adds minimal value beyond the schema, only implying that 'parameter value' drives color assignment without explaining how values map to colors or what happens with null/missing values.
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 ('color elements') and specifies the mechanism ('based on a category and parameter value'), distinguishing it from sibling tools like 'get_current_view_elements' or 'delete_element'. However, it doesn't explicitly differentiate from tools like 'operate_element' that might also affect element appearance.
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, or comparisons to sibling tools like 'tag_all_walls' for visualization purposes.
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 units are in millimeters and supports batch creation, but doesn't cover permissions needed, whether creation is reversible, error handling, or what happens on partial failure in batch operations. For a creation tool with zero annotation coverage, this is insufficient.
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 efficiently structured in two sentences: first stating purpose and examples, second detailing parameters and units. It's front-loaded with the core functionality and avoids unnecessary repetition, though it could be slightly more polished.
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 creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure, element IDs), doesn't mention error conditions, and provides minimal behavioral context. Given the complexity of creating multiple Revit elements, more 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds marginal value by listing parameters (family type ID, start/end points, thickness, height, level information) and confirming units are in mm, but doesn't provide additional syntax, constraints, or examples beyond what the schema already specifies.
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 creates line-based elements in Revit with specific examples (walls, beams, pipes) and mentions batch creation. It distinguishes from siblings like create_point_based_element and create_surface_based_element by specifying 'line-based' elements, though it doesn't explicitly contrast them.
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 like create_point_based_element or create_surface_based_element. It mentions batch creation but doesn't specify prerequisites, limitations, or typical use cases beyond the basic functionality.
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 provides minimal behavioral context. It mentions batch creation and units (mm), but doesn't disclose critical behaviors: whether this is a write operation (implied but not stated), what happens on failure, whether elements are immediately visible, if it requires specific Revit document states, or any permissions/rate limits. The description adds some value but leaves significant gaps for a mutation tool.
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?
Two sentences with zero waste. First sentence states purpose and scope, second adds unit information. Appropriately front-loaded with the core functionality. Could be slightly more structured with bullet points for key features but remains efficient.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns element IDs? success status?), doesn't mention error conditions, and provides minimal behavioral context. Given the complexity of creating Revit elements with multiple parameters, more guidance on usage and outcomes 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds marginal value by mentioning 'detailed parameters including family type ID, position, dimensions, and level information' and 'units are in millimeters (mm)', which reinforces schema details but doesn't provide new semantic context beyond what's already in parameter descriptions.
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 creates point-based elements in Revit with specific examples (doors, windows, furniture) and mentions batch creation capability. It distinguishes from siblings like 'create_line_based_element' and 'create_surface_based_element' by specifying 'point-based', but doesn't explicitly contrast with other creation 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?
No guidance on when to use this tool versus alternatives like 'create_line_based_element' or 'create_surface_based_element'. The description mentions 'point-based elements' but doesn't explain what qualifies as point-based versus line-based or surface-based, nor does it mention prerequisites like needing valid family type IDs from 'get_available_family_types'.
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, the description carries full burden but only states the basic action. It lacks critical behavioral details: whether deletion is permanent/reversible, permission requirements, rate limits, error handling for invalid IDs, or effects on the model. This is a significant gap 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 front-loads the key action ('Delete') and resource ('elements'), making it easy to scan and understand quickly.
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 destructive nature, no annotations, and no output schema, the description is incomplete. It fails to address safety, permissions, or result expectations, leaving the agent under-informed about critical behavioral aspects.
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' fully documented in the schema. The description adds no additional meaning beyond implying the IDs are for deletion, matching the baseline score when 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 action ('Delete') and target ('elements from the Revit model'), specifying the mechanism ('by their element IDs'). It distinguishes from siblings like 'operate_element' or 'get_selected_elements' by focusing on deletion, but doesn't explicitly contrast with other destructive tools if they exist.
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?
No guidance is provided 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), or suggest related tools like 'get_selected_elements' for obtaining IDs, leaving usage context implied at best.
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 mentions the ability to limit returned elements but doesn't explain what happens if no elements are selected (e.g., returns empty list or error), how selection state is determined, or any performance implications. This leaves significant gaps for a tool that interacts with a complex system like Revit.
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 brief and front-loaded, with the core purpose stated first and an additional feature mentioned second. Both sentences earn their place by clarifying functionality, though it could be slightly more structured (e.g., explicitly stating it's for retrieving user-selected elements).
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 interacting with Revit and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'elements' refer to in Revit context (e.g., walls, doors), the format of returned data, error conditions, or dependencies on user interaction. For a tool in a specialized domain with no structured output, more detail 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%, with the single parameter 'limit' clearly documented in the schema as 'Maximum number of elements to return'. The description adds minimal value beyond this, only mentioning 'You can limit the number of returned elements' without providing additional context like default behavior if limit is omitted or practical usage tips.
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 elements currently selected') and resource ('in Revit'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_current_view_elements' or 'ai_element_filter', which might also retrieve elements in different contexts.
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 sibling tools like 'get_current_view_elements' (which retrieves elements from the current view) or 'ai_element_filter' (which might filter elements differently), leaving the agent without context for choosing between them.
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 and mentions units (mm), but lacks critical details such as permission requirements, whether changes are reversible, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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 efficiently structured in two sentences, front-loading the purpose and key features (batch creation, parameters, units). There is no wasted text, though it could be slightly more detailed in behavioral aspects without losing conciseness.
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 complex mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., permissions, side effects), output format, error conditions, and usage guidelines. The high schema coverage does not compensate for these gaps in 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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'family type ID, boundary lines, thickness, and level information', which are already covered in the schema. It does not provide additional syntax, constraints, or examples beyond the schema.
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 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 like 'create_line_based_element' or 'create_point_based_element'. It mentions batch creation and parameters but does not specify prerequisites, exclusions, or comparative contexts, leaving the agent without usage direction.
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 mentions code execution within a template and access to Document/parameters, it doesn't disclose critical behavioral aspects like authentication requirements, execution environment constraints, error handling, or whether this operation is reversible/destructive. For a code execution tool with zero annotation coverage, this represents significant 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 appropriately concise with two sentences that each serve a purpose: the first states the core functionality, the second provides important implementation context about the template structure. There's no wasted verbiage, though it could be slightly more front-loaded with critical behavioral information.
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 code execution tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after execution (success/failure responses, return values, error formats), doesn't mention security implications of executing arbitrary code, and provides minimal guidance about the execution environment. Given the complexity and potential risks of code execution, more comprehensive description 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?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description mentions that code will be inserted into a template with access to Document and parameters, which adds some context about how the 'code' parameter will be used, but doesn't provide additional semantic meaning 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 this from sibling tools that manipulate elements or retrieve data rather than executing custom code. The phrase 'for execution' provides clear functional differentiation.
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?
No guidance is provided about when to use this tool versus alternatives. While the description implies this is for executing custom C# code in Revit, it doesn't specify prerequisites, appropriate use cases, or when other tools like 'operate_element' might be more suitable. The description lacks explicit when/when-not 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering and limiting returns, but fails to cover critical aspects like whether this is a read-only operation (implied by 'Get' but not stated), potential performance impacts, error handling, or output format. For a tool with 3 parameters and no annotations, 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, well-structured sentence that efficiently communicates the tool's purpose and key features without any wasted words. It is front-loaded with the main action and includes essential details, making it easy to grasp quickly.
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 tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., read-only nature, error conditions), output format, and how it integrates with sibling tools. This makes it inadequate for an agent to fully understand and invoke the tool correctly in 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?
The description adds value by summarizing the filtering and limiting capabilities ('filter by category and family name, and limit the number of returned types'), which aligns with the parameters in the schema. Since schema description coverage is 100%, the baseline is 3, and the description provides a high-level overview without adding detailed semantics beyond what the schema already documents.
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 ('Get') and resource ('available family types in the current Revit project'), making the purpose understandable. It distinguishes itself from siblings like 'get_current_view_elements' or 'get_selected_elements' by focusing on family types rather than elements or views, though it doesn't explicitly name alternatives for similar queries.
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 by mentioning filtering capabilities ('You can filter by category and family name'), which suggests when to use it for targeted queries. However, it lacks explicit guidance on when not to use it or alternatives among siblings, such as comparing to 'ai_element_filter' or other element-related tools.
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 a read-only operation, but doesn't clarify if it requires specific permissions, has side effects, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and safety profile.
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 that front-loads the core purpose ('获取 Revit 当前活动视图的详细信息') and adds clarifying examples ('包括视图类型、名称、比例等属性'). There is no wasted text, and it directly addresses what the tool does without unnecessary elaboration.
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 simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It explains the purpose and examples of returned attributes, but lacks details on behavioral traits, usage context, or output format. Without annotations or an output schema, more completeness would be beneficial, but it meets a basic threshold for this low-complexity tool.
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 input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Since there are no parameters to explain, a baseline score of 4 is applied, as the description doesn't need to compensate for any schema gaps.
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 might retrieve elements within the view 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 prerequisites (e.g., needing an active Revit session), exclusions, or comparisons to siblings like 'get_current_view_elements' (which might focus on elements in the view). Usage is implied only by the tool's name and purpose, with no explicit context for selection.
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 the full burden. It implies mutation through actions like 'delete' and 'setColor', but lacks details on permissions, reversibility, or side effects. The action list hints at behavior, but critical aspects like 'Delete permanently removes elements' are buried in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists actions, but it's front-loaded without prioritization. It could be more structured by grouping actions or highlighting common uses, though it avoids redundancy.
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 tool with no annotations and no output schema, the description is moderately complete. It covers the tool's purpose and action types, but lacks usage guidelines, error handling, or output details, leaving gaps for the agent to navigate.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by listing action examples (e.g., 'select, selectionBox, setColor'), which clarifies the tool's scope beyond the schema's generic 'action' parameter, though it doesn't detail all parameters or their interactions.
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 performs operations on Revit elements and lists specific actions like select, delete, hide, etc. It distinguishes itself from siblings like 'delete_element' by being a multi-action tool, though it doesn't explicitly contrast with other siblings like 'color_elements'.
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, context, or compare with sibling tools like 'delete_element' or 'color_elements', leaving the agent to infer usage from action names alone.
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 states the tool creates tags but doesn't mention whether this is a destructive operation (modifying the model), what permissions are required, whether it's reversible, or what happens on failure. The description adds basic context about tag placement but lacks critical behavioral details for a mutation tool.
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 states the core purpose and scope, while the second adds important placement details. There's zero wasted language or redundancy.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (success/failure indicators, created tag IDs, etc.), error conditions, or important behavioral constraints. While concise, it lacks the completeness needed for an agent to use this tool confidently in a complex environment like Revit.
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 both parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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 'get_current_view_elements' or 'create_point_based_element' 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 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 (like needing an active view with walls), exclusions, or comparisons to sibling tools like 'operate_element' or 'create_point_based_element' that might handle similar operations. The context 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.
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. It discloses some behavioral traits: it's a read operation ('Get'), mentions filtering by categories, and describes what 'includeHidden' and 'limit' do. However, it lacks details on permissions, rate limits, error conditions, or what happens if no view is active, leaving gaps for a mutation-free tool.
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 front-loaded with the core purpose, followed by concise explanations of key parameters. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 no annotations and no output schema, the description is moderately complete. It covers the tool's purpose and parameters but lacks details on return values, error handling, or dependencies. For a read tool with 4 parameters, it's 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.
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 briefly mentioning 'model categories' and 'annotation categories' and explaining 'includeHidden' and 'limit' in simple terms, but it doesn't provide additional syntax or format details beyond the schema. Baseline 3 is appropriate here.
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 from the current active view in Revit.' It specifies the verb ('Get') and resource ('elements'), and mentions filtering capabilities. However, it doesn't explicitly differentiate from sibling tools like 'get_selected_elements' or 'get_current_view_info', which would require a 5.
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 by mentioning filtering options and parameters like 'includeHidden' and 'limit', but it doesn't provide explicit guidance on when to use this tool versus alternatives. For example, it doesn't compare to 'get_selected_elements' or specify prerequisites like needing an active view.
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 effectively explains that this is a read-only querying tool (implied by 'retrieve' and 'querying'), but lacks details on performance constraints (beyond the example's mention of post-processing), error conditions, or authentication requirements. The example adds practical context about how returned data should be processed, which is helpful but not comprehensive.
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 well-structured with a clear purpose statement followed by a detailed example. While slightly verbose, every sentence adds value: the first establishes the tool's role, the second explains the workflow, and the example concretely demonstrates usage. It could be more concise by tightening the example explanation, but overall it's efficiently front-loaded with key information.
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 complexity (multiple filtering parameters, no output schema, no annotations), the description does a good job explaining the tool's role and workflow. The detailed example compensates for the lack of output schema by showing how returned data should be processed. However, it doesn't fully address all behavioral aspects like performance limits or error handling that would be needed for complete understanding.
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 parameter-specific semantics beyond the example showing filterCategory and includeInstances usage. It doesn't explain parameter interactions or provide additional syntax guidance beyond what's in the schema descriptions, meeting 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 tool's purpose with specific verbs ('retrieve detailed element information', 'querying tool') and resources ('Revit elements', 'Revit projects'). It distinguishes from siblings by emphasizing its role as an intelligent filtering tool for AI assistants, unlike tools like delete_element or create_line_based_element which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool through a detailed example scenario ('When a user asks...'), showing how the AI should invoke it for complex queries. It implicitly distinguishes from siblings like get_selected_elements (which retrieves pre-selected elements) or get_current_view_elements (which focuses on current view visibility) by emphasizing flexible filtering across the entire project.
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-github-copilot MCP server](https://glama.ai/mcp/servers/Mohamed-Elnahla/revit-mcp-github-copilot/badges/card.svg)](https://glama.ai/mcp/servers/Mohamed-Elnahla/revit-mcp-github-copilot)

Score Badge

Copy to your README.md:

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

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/Mohamed-Elnahla/revit-mcp-github-copilot'

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