Revit MCP
Server Details
Revit model integration via APS — elements, parameters, schedules, clashes, IFC export.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.8/5 across 8 of 8 tools scored.
Each tool has a uniquely defined purpose (clash detection, export, element retrieval, parameter schema, sheets, views, schedule, upload). Overlap between get_views and get_sheets is clearly disambiguated in descriptions.
All tools follow a consistent 'revit_verb_noun' pattern using snake_case, making the naming predictable and intuitive.
With 8 tools, the server covers core Revit workflows (upload, export, clash detection, element queries, schedules, views) without being bloated or sparse.
The set covers essential read operations and file ingestion/export well. Minor gaps: no explicit model status check tool or tool to list existing models (though upload implies onboarding). Overall, the surface feels complete for typical interactions.
Available Tools
8 toolsrevit_clash_detectAInspect
When to use: Perform a lightweight clash analysis between two Revit categories (e.g. Mechanical Equipment vs Structural Framing) using bounding-box overlap where available, falling back to shared-Level proximity, then annotate with any matching VDC rules stored in the D1 database. When NOT to use: Do not use as a substitute for Navisworks Manage for contractual clash reports — this is a first-pass coordination sniff test, not a certified Clash Detective run. APS scopes: data:read viewables:read (Model Derivative metadata + properties). Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired — refresh. 403 scope insufficient — add viewables:read. 404 URN not found — verify model_id. 429 rate limited — back off. 5xx APS upstream — retry with jitter. Side effects: Read-only against APS. May read from D1 vdc_rules table if present. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | Base64url-encoded URN of the translated Revit model. Always begins with 'dXJu'. | |
| category_a | Yes | First Revit category for the pairwise clash check (case-insensitive substring match). Typical MEP/structural examples: Mechanical Equipment, Ducts, Pipes, Cable Trays. | |
| category_b | Yes | Second Revit category to compare against category_a. Often a structural/architectural discipline when category_a is MEP. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It comprehensively discloses side effects (read-only against APS, reads D1 if present, idempotent), rate limits, error codes, and APS scope requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (When to use, When NOT to use, etc.) and is front-loaded with purpose. Some redundancy could be trimmed, but each section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 covers purpose, limitations, error handling, side effects, and behavioral details thoroughly. It is complete for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal parameter context (e.g., case-insensitive substring match for categories) but does not significantly enhance meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a lightweight clash analysis between two Revit categories using bounding-box overlap or proximity, and annotates with VDC rules. It distinguishes from sibling tools like revit_export_ifc or revit_get_elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (first-pass coordination sniff test) and when not to use (not a substitute for Navisworks Manage). Also provides prerequisites like APS scopes and rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revit_export_ifcAInspect
When to use: Kick off a Model Derivative translation of a previously uploaded Revit URN into IFC (IFC2x3 Coordination View 2.0 by default) so the model can be exchanged with non-Autodesk tools (Solibri, BIMcollab, Tekla, openBIM workflows). When NOT to use: Do not use for SVF/SVF2 web viewing (that happens automatically in revit_upload), and do not call repeatedly while a prior IFC job is still inprogress — poll the manifest instead. APS scopes: data:read data:write viewables:read (Model Derivative job + manifest). Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired — refresh. 403 scope insufficient — add data:write. 404 URN not found — confirm model_id was translated. 409 not applicable. 429 rate limited — back off. 5xx APS upstream — retry with jitter up to 3x. Side effects: Creates a Model Derivative job and, on completion, a new IFC derivative inside the model's manifest. Safe to re-run (APS deduplicates) but each call with x-ads-force may retranslate.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | Base64url-encoded URN of the translated Revit model to export to IFC. Always begins with 'dXJu'. | |
| include_properties | No | Whether to include Revit property sets in the IFC output. true -> IFC2x3 Coordination View 2.0 (with psets); false -> minimal IFC2x3 geometry. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses side effects (Model Derivative job, IFC derivative in manifest), deduplication behavior, safe-to-re-run, and details on error codes and rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with clear headings and sections. Slightly long but every sentence adds value. Could be trimmed slightly but remains readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains output implicitly (IFC derivative). Covers prerequisites, error handling, side effects, rate limits, and duplicates—complete for a two-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both params. Description adds context like default IFC version and effect of include_properties (with/without psets). Slight extra value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Kick off Model Derivative translation to IFC), the resource (previously uploaded Revit URN), and distinguishes from sibling revit_upload (which auto-converts for web viewing). The use case for openBIM workflows is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists 'When to use' and 'When NOT to use', including alternatives (revit_upload, polling manifest). Also covers rate limits, error codes, and prerequisites, giving comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revit_get_elementsAInspect
When to use: After a Revit model has finished translating, fetch the first ~100 elements belonging to a Revit category (e.g. Walls, Doors, Windows, Structural Columns) with their objectid, name, externalId, and property bag. When NOT to use: Do not call before translation completes (manifest.status must be success), and do not use for free-text searches across the whole model — filter by category here or use revit_run_schedule for tabular views. APS scopes: data:read viewables:read (Model Derivative metadata + properties). Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired — refresh. 403 scope insufficient — add viewables:read. 404 URN not found — confirm model_id and that translation has run. 429 rate limited — back off. 5xx APS upstream — retry with jitter. Side effects: Read-only. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Revit category name to filter on (case-insensitive substring match). Use canonical Revit category names like Walls, Doors, Windows, Structural Columns, Ducts, Pipes, Mechanical Equipment. | |
| model_id | Yes | Base64url-encoded URN of the translated Revit model (returned from revit_upload as model_id/urn). Always begins with 'dXJu' (base64 of 'urn:'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully compensates by detailing side effects (read-only, idempotent), error codes (401, 403, 404, 429, 5xx), rate limits (~50 req/min), and required scopes (data:read, viewables:read). This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear section headers (When to use, When NOT to use, APS scopes, etc.). Every sentence adds value; no redundant or tautological content. Front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only element listing tool with no output schema, the description covers prerequisites, error handling, and return fields. Missing details on pagination or how to get more than 100 elements, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds minimal extra meaning beyond the schema (e.g., case-insensitive substring match is already in schema). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches the first ~100 Revit elements by category, listing specific fields returned (objectid, name, externalId, property bag). It distinguishes from sibling tools like revit_get_parameters and revit_get_sheets by focusing on category-based element retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after translation completes) and when not to use (before translation, for free-text search). Provides an alternative tool (revit_run_schedule for tabular views). This gives clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revit_get_parametersAInspect
When to use: Enumerate the Revit parameters (type + instance) that appear on elements in a given category, or on one specific element by objectid. Returns unique values per parameter and how many elements carry it — ideal for schema discovery before building a schedule. When NOT to use: Do not use when you just need the elements themselves (use revit_get_elements), or to modify values — this is read-only. APS scopes: data:read viewables:read (Model Derivative metadata + properties). Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired — refresh. 403 scope insufficient — add viewables:read. 404 URN not found — verify model_id. 429 rate limited — back off. 5xx APS upstream — retry with jitter. Side effects: Read-only. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Revit category to filter on (case-insensitive substring match). Ignored when element_id is supplied. | |
| model_id | Yes | Base64url-encoded URN of the translated Revit model (returned from revit_upload). Always begins with 'dXJu'. | |
| element_id | No | Optional APS Model Derivative objectid of a single element to inspect. When provided, overrides category filtering and returns parameters only for that element. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses read-only, idempotent nature, side effects, error codes, and rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded purpose, but slightly verbose for an agent; still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return values (unique values per parameter, count). Covers prerequisites, errors, and usage context thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining case-insensitive substring match for category, model_id pattern, and element_id overriding behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it enumerates Revit parameters for a category or specific element, distinguishing from sibling tools like revit_get_elements and revit_run_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with alternatives, plus details on APS scopes, rate limits, errors, and side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revit_get_sheetsAInspect
When to use: Enumerate the drawing sheets (title blocks with sheet number + sheet name like 'A-101: First Floor Plan') published from a translated Revit model, so an agent can pick which sheet to render, review, or cross-reference. When NOT to use: Do not use to list model views like floor plans or 3D views (use revit_get_views) — this returns only 2D sheet entries. APS scopes: data:read viewables:read (Model Derivative metadata + object tree). Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired — refresh. 403 scope insufficient — add viewables:read. 404 URN not found — check model_id. 429 rate limited — back off. 5xx APS upstream — retry with jitter. Side effects: Read-only. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | Base64url-encoded URN of the translated Revit model whose sheets you want to list. Always begins with 'dXJu'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses read-only, idempotent nature, side effects, rate limits, and common errors, leaving no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections like 'When to use' and 'Errors', but slightly verbose; however, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking annotations and output schema, description covers return format (sheet number + name), usage, errors, rate limits, and side effects, fully equipping an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers model_id with pattern, examples, and description; the tool description adds context by linking it to 'translated Revit model', enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool enumerates drawing sheets with specific details and distinguishes from revit_get_views for listing model views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections, points to alternative tool, and provides scope, rate limit, and error handling guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revit_get_viewsAInspect
When to use: Return every view (both 2D — floor plans, ceiling plans, elevations, sections, sheets — and 3D — default {3D}, perspective views, isometric views) in the translated Revit model, including each view's GUID, name, role, and whether it is the master view. When NOT to use: Do not use when you only want drawing sheets (use revit_get_sheets) or element data inside a view (use revit_get_elements / revit_run_schedule). APS scopes: data:read viewables:read (Model Derivative metadata + object tree). Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired — refresh. 403 scope insufficient — add viewables:read. 404 URN not found — check model_id. 429 rate limited — back off. 5xx APS upstream — retry with jitter. Side effects: Read-only. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | Base64url-encoded URN of the translated Revit model whose views you want to list. Always begins with 'dXJu'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only, idempotent nature, APS scopes, rate limits, and common errors. Lacks mention of pagination or empty result handling, but overall thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections, front-loaded with purpose, each section adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what is returned (list with fields), error handling, scopes, and side effects; no output schema needed given description details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter; description adds pattern, examples, and explicit note about URN prefix, enhancing schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns every view (2D and 3D) with specific details, and distinguishes from siblings like revit_get_sheets and revit_get_elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'when to use' and 'when NOT to use' sections, naming alternative tools for specific needs, providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revit_run_scheduleAInspect
When to use: Build a tabular, spreadsheet-style schedule (rows = elements matching a keyword, columns = up to 15 shared parameters) from a translated Revit model — useful for Door Schedules, Wall Schedules, Room Schedules, and QA/QC exports. When NOT to use: Do not use when you only need raw element metadata (use revit_get_elements) or parameter schema (use revit_get_parameters). APS scopes: data:read viewables:read (Model Derivative metadata + properties). Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired — refresh. 403 scope insufficient — add viewables:read. 404 URN not found — check model_id. 429 rate limited — back off. 5xx APS upstream — retry with jitter. Side effects: Read-only. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | Base64url-encoded URN of the translated Revit model. Always begins with 'dXJu'. | |
| schedule_name | Yes | Category name or keyword used to select rows (case-insensitive substring match on Category/name). Common examples: Walls, Doors, Windows, Rooms, Furniture, Mechanical Equipment. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers all behavioral traits: side effects (read-only, idempotent), APS scopes, rate limits, error codes with remediation. Thorough disclosure beyond what structured fields convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear section headings, front-loaded with key guidance, no wasted words. Each section earns its place with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return format (tabular schedule) and filtering logic. Covers scopes, errors, and side effects. Distinguishes from siblings. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining schedule_name is a case-insensitive substring match on Category/name and providing common examples. Also clarifies output is tabular with up to 15 columns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds tabular schedules from a Revit model, specifies rows/columns limits, and gives concrete examples (Door, Wall, Room Schedules). It also distinguishes from siblings like revit_get_elements and revit_get_parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections with named alternatives and specific use cases. Provides clear context for when to invoke vs other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revit_uploadAInspect
When to use: Ingest a Revit (.rvt / .rfa / .rte / .rft) file into Autodesk Platform Services by downloading it from a publicly reachable URL, uploading it to an OSS bucket, and starting an SVF2 translation so downstream revit_* tools can read elements, parameters, sheets, and views. When NOT to use: Do not call if you already have a translated URN (use the existing model_id instead), if the file is not a Revit source file, or if the URL requires authentication the worker cannot satisfy. APS scopes: data:read data:write data:create bucket:read bucket:create viewables:read (OSS bucket create + object PUT + Model Derivative job). Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired — refresh credentials and retry. 403 scope insufficient — request data:write + bucket:create. 404 bucket/object not found — confirm bucket was created. 409 bucket exists — safe to ignore, reuse it. 429 rate limited — back off with exponential delay. 5xx APS upstream — retry with jitter up to 3x, then surface. Side effects: Creates a new transient OSS bucket named scanbim-revit-, uploads the object, and starts a Model Derivative translation job. NOT idempotent — each call creates a fresh bucket and new URN.
| Name | Required | Description | Default |
|---|---|---|---|
| file_url | Yes | Public HTTPS URL the worker can fetch the Revit file from. Must return 200 with the raw .rvt bytes (no auth gate, no HTML redirect). Max 100MB for direct upload. | |
| file_name | Yes | Original file name including the Revit extension (.rvt, .rfa, .rte, .rft). Used as the OSS object key; non-alphanumeric characters are sanitized to underscores. | |
| project_name | No | Optional human-readable project label echoed back in the response for bookkeeping. No effect on APS processing. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses side effects (creates bucket, uploads object, starts translation, not idempotent), errors, rate limits, and required scopes comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (When to use, When NOT to use, APS scopes, Rate limits, Errors, Side effects). Front-loaded purpose, each sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (multi-step process, no output schema), description covers inputs, process, side effects, error handling, rate limits, and scopes. Complete for agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions; the description adds extra context like OSS bucket naming convention and purpose of project_name for bookkeeping. Slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it ingests a Revit file via URL uploads to OSS bucket and starts SVF2 translation for downstream tools. Distinguishes from sibling revit_* tools by context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (Revit file ingestion) and when NOT to use (already translated URN, not Revit file, URL requires auth). Provides clear alternative usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!