ACC MCP
Server Details
Autodesk Construction Cloud via APS — projects, issues, RFIs, documents, submittals.
- 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.7/5 across 9 of 9 tools scored.
Each tool targets a distinct entity (issue, RFI, project, document, file) and action (create, list, update, search, upload, summary). The 'When to use' and 'When NOT to use' notes in descriptions further prevent confusion.
All tools follow a consistent acc_verb_noun pattern (e.g., acc_create_issue, acc_list_projects, acc_upload_file). Verbs are always lowercase, nouns are singular, and there are no mixed conventions.
9 tools is well-scoped for an ACC MCP server. It covers core project management operations (issues, RFIs, projects, documents, file upload) without being too sparse or bloated.
The set covers create, read (list), and update for issues, plus create and list for RFIs. Missing update for RFIs and a dedicated get-by-ID for individual issues or RFIs are minor gaps, but the core workflows are supported.
Available Tools
9 toolsacc_create_issueAInspect
Create a new ACC issue (field observation, coordination clash, safety, quality, etc.) in the target project via the APS Construction Issues API.
When to use: The user wants to log a new issue — e.g. 'open a high-priority issue about the leaking valve on level 3' or a downstream agent detected a defect during a model review and needs to record it for the project team.
When NOT to use: Do not use to modify an existing issue (use acc_update_issue) and do not use for RFIs (use acc_create_rfi).
APS scopes: data:read data:write account:read.
Rate limits: ACC Issues API limited to ~100 req/min per app; APS default ~50 req/min per endpoint — batch creations with backoff.
Errors: 401 (APS token expired — refresh); 403 (user lacks 'Create Issues' permission on the project or scope insufficient — surface to user); 404 (project_id not found — verify the 'b.' prefix and that the project belongs to a hub the app can see via acc_list_projects); 422 (validation — required field like title/description missing or priority enum invalid); 429 (rate limit — retry after 60s); 5xx (ACC upstream — retry with jitter, do not double-create).
Side effects: Creates a persistent issue record visible to all project members. NOT idempotent — a retry on a 5xx may create duplicates; dedupe by title before retrying.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Short issue title, 1–255 chars. Required. | |
| due_date | No | Optional due date in ISO 8601 date format (YYYY-MM-DD). | |
| priority | No | Issue priority. Defaults to 'medium' if omitted. | |
| project_id | Yes | ACC project ID. MUST use the 'b.' prefix literal (e.g. 'b.a1b2c3d4-...'). The worker strips the prefix internally for the Issues endpoint. Obtain via acc_list_projects. | |
| assigned_to | No | Optional APS user ID (oxygen ID / ACC user UUID) of the assignee. Leave null for unassigned. | |
| description | Yes | Detailed issue description / body. Plain text, up to ~10,000 chars. Required. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full weight. It discloses side effects (persistent record, not idempotent), rate limits (100 req/min, 50 req/min), and detailed error codes with remediation, providing complete behavioral transparency.
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 (purpose, usage, scopes, rate limits, errors, side effects). While somewhat lengthy, every sentence serves a purpose and no information is redundant, making it effective without being wasteful.
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 creation tool with no output schema, the description covers usage context, error handling, side effects, and prerequisites comprehensively. However, it does not describe expected return values (e.g., the created issue object), which is a minor gap for completeness.
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 description coverage is 100%, but the description adds significant value beyond the schema: it explains the 'b.' prefix for project_id, default priority, ISO 8601 format for due_date, and usage context for each parameter, enhancing semantic 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?
The description clearly states the tool's purpose: 'Create a new ACC issue' and enumerates specific types (field observation, coordination clash, safety, quality). It distinguishes from sibling tools like acc_update_issue and acc_create_rfi, ensuring clarity.
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 usage guidance is provided: 'When to use' with concrete examples, and 'When NOT to use' with specific alternatives. Additionally, it covers APS scopes, rate limits, and error handling, giving agents robust decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acc_create_rfiAInspect
Create a new Request For Information (RFI) in an ACC project via the APS Construction RFIs API. RFI is created in 'draft' status — the project workflow owner typically transitions it to 'submitted'.
When to use: The user needs a formal question-of-record to the design or GC team — e.g. 'raise an RFI asking for clarification on the Level 2 beam schedule'. RFIs are the auditable channel for clarifications; issues are for field observations.
When NOT to use: Do not use for informal observations (use acc_create_issue) or to answer an existing RFI (not supported here).
APS scopes: data:read data:write account:read.
Rate limits: APS default ~50 req/min per endpoint per app. RFIs share the Construction API umbrella with issues (~100 req/min combined).
Errors: 401 (APS token expired — refresh); 403 (user lacks RFI create permission on project); 404 (project_id not found — verify 'b.' prefix and hub membership); 422 (validation — subject/question missing or priority enum invalid); 429 (rate limit — back off 60s); 5xx (ACC upstream — retry with jitter, check for duplicate before retrying).
Side effects: Creates a persistent RFI record. NOT idempotent — retry on 5xx risks duplicates; dedupe by subject before retrying.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | Short RFI subject/title, 1–255 chars. Required. | |
| priority | No | RFI priority. Defaults to 'medium' if omitted. | |
| question | Yes | Full RFI question body. Plain text, up to ~10,000 chars. Required. | |
| project_id | Yes | ACC project ID. MUST use 'b.' prefix literal. Obtain via acc_list_projects. | |
| assigned_to | No | Optional APS user ID of the person the RFI is directed to. |
Tool Definition Quality
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 draft status, idempotency, error codes with handling, side effects, API scopes, and rate limits. Missing response structure, but otherwise 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 clear sections. Front-loaded with core purpose. Every sentence adds value, no redundancy. Appropriate length for the complexity.
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 purpose, usage, behavior, errors, side effects. Lacks explicit return value description, but given no output schema, it's mostly complete for an agent. Differentiates well from siblings.
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 description coverage is 100%, so baseline is 3. The description adds minimal new meaning to parameters beyond schema (e.g., project_id retrieval advice). No significant compensation needed.
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 creates an RFI in ACC via APS Construction RFIs API. It distinguishes from sibling acc_create_issue by explicitly stating when not to use it and directing to the alternative.
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?
Provides explicit 'When to use' and 'When NOT to use' sections, referencing sibling tools. Covers alternatives and context, making it easy for an agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acc_list_issuesAInspect
List and filter issues from a single ACC project (limit 50 per call) via the APS Construction Issues API.
When to use: The user or upstream agent needs to review open issues, count issues by status/priority, or look up an issue_id before calling acc_update_issue. E.g. 'show me all critical open issues on the Tower project'.
When NOT to use: Do not use to fetch RFIs (use acc_list_rfis) or to search documents.
APS scopes: data:read account:read. No write scope required.
Rate limits: ACC Issues API ~100 req/min per app; results pageable (limit 50 here, max 200 upstream). For large projects, call once and filter client-side instead of looping.
Errors: 401 (APS token expired — refresh); 403 (user lacks 'View Issues' permission on project or scope insufficient); 404 (project_id not found — verify 'b.' prefix and hub membership via acc_list_projects); 422 (invalid filter value — check status/priority spelling); 429 (rate limit — back off 60s); 5xx (ACC upstream — retry with jitter).
Side effects: None. Read-only and idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Optional status filter. Typical values: open, in_review, closed, draft. | |
| priority | No | Optional priority filter. Typical values: critical, high, medium, low. | |
| project_id | Yes | ACC project ID. MUST use 'b.' prefix literal. Obtain via acc_list_projects. | |
| assigned_to | No | Optional assignee APS user ID filter. Accepted but not currently forwarded as a URL filter by this server — filter client-side if needed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully covers behavior: specifies read-only and idempotent nature, required APS scopes, rate limits, and detailed error codes with causes. This is comprehensive beyond typical 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but somewhat verbose. Every sentence adds value, yet the error list is lengthy. Could be tightened slightly, but front-loaded purpose makes it effective.
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 authentication, rate limits, errors, and side effects thoroughly. Lacks explicit pagination details (e.g., offset/cursor) beyond the limit, which would improve completeness. Still very strong given no output schema or annotations.
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%, but the description adds critical details: project_id must use 'b.' prefix, assigned_to filter is not forwarded server-side, and typical values for status and priority. These enrich the schema's basic 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 lists and filters issues from a single ACC project with a limit of 50 per call. It uses a specific verb and resource, and distinguishes from siblings like acc_list_rfis and acc_search_documents.
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?
Includes explicit 'When to use' and 'When NOT to use' sections, with examples and alternative tools. Also provides guidance on filtering client-side for large projects instead of looping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acc_list_projectsAInspect
Enumerate every ACC and BIM 360 project the authenticated APS app can see by walking all accessible hubs and their project lists.
When to use: The agent needs to discover project IDs before calling any other tool (e.g. the user says 'show me my projects' or 'find issues in the Tower project' and no project_id is known yet). Also useful to confirm hub membership for a project.
When NOT to use: Do not call this repeatedly in a loop — cache the result; if the user already supplied a project_id starting with 'b.', skip discovery.
APS scopes: data:read account:read. No write scope needed.
Rate limits: APS default ~50 req/min per app per endpoint; BIM 360 hubs endpoints are pageable (limit 200). This tool fans out 1 hubs call + N project calls (one per hub) so call it sparingly on tenants with many hubs.
Errors: 401 (APS token expired — refresh and retry once); 403 (app not provisioned in the BIM 360/ACC account — ask user to have an account admin add the APS client_id); 404 (rare, indicates hub deleted mid-call); 429 (rate limit — back off 60s); 5xx (ACC upstream — retry with jitter).
Side effects: None. Read-only and idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior: read-only, idempotent, no side effects, APS scopes needed, rate limits, and detailed error handling.
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, though slightly verbose. Every sentence adds value, but could be more concise without losing 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 parameters and no output schema, the description covers behavior, use cases, error handling, rate limits, and side effects comprehensively. No gaps.
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?
Zero parameters with 100% schema coverage. Baseline is 4. The description explains that no input is needed, which is consistent and sufficient.
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 uses specific verbs ('Enumerate', 'walk') and clearly identifies the resource ('ACC and BIM 360 projects'), distinguishing it from siblings that deal with issues or RFIs.
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 (discover project IDs before other calls) and when NOT to use (don't loop, skip if project_id starts with 'b.'), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acc_list_rfisAInspect
List and filter RFIs from a single ACC project (limit 50 per call) via the APS Construction RFIs API.
When to use: The user wants to review open RFIs, count outstanding ones, or look up an RFI ID. E.g. 'how many RFIs are still open on the Tower project?'
When NOT to use: Do not use for issues (use acc_list_issues) or document search (use acc_search_documents).
APS scopes: data:read account:read. No write scope required.
Rate limits: APS default ~50 req/min per endpoint; ACC Construction API shared ~100 req/min cap. Pageable (limit 50 here; upstream max 200).
Errors: 401 (APS token expired — refresh); 403 (user lacks RFI view permission); 404 (project_id not found — verify 'b.' prefix and hub membership); 422 (invalid filter value); 429 (rate limit — back off 60s); 5xx (ACC upstream — retry).
Side effects: None. Read-only and idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Optional RFI status filter. Typical values: draft, submitted, open, answered, closed, void. | |
| project_id | Yes | ACC project ID. MUST use 'b.' prefix literal. Obtain via acc_list_projects. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: read-only, idempotent, no side effects, APS scopes, rate limits, and detailed error handling (401,403,404,422,429,5xx). This exceeds minimal 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?
Well-structured with labeled sections (When to use, When NOT to use, APS scopes, Rate limits, Errors, Side effects). Every sentence adds value, though slightly verbose; could be tightened slightly without losing clarity.
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 or output schema, the description covers usage, limits, scopes, errors, and side effects thoroughly. Lacks explicit return format description, but this is acceptable for a list tool with clear purpose.
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 clear descriptions for both parameters. The description adds overall tool context (limit 50) but does not enhance parameter semantics beyond what the schema already provides. Baseline 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 the tool lists and filters RFIs from a single ACC project with a limit of 50 per call. It provides specific verb and resource, and explicitly distinguishes from siblings like acc_list_issues and acc_search_documents.
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?
Provides explicit when-to-use scenarios (review open RFIs, count outstanding ones, look up an RFI ID) and when-not-to-use (issues, document search). Includes a concrete example query, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acc_project_summaryAInspect
Fetch the full ACC project metadata record (name, type, status, dates, extension attributes) for a single project via APS Data Management. If hub_id is omitted the tool picks the first accessible hub, which may be wrong on multi-hub tenants.
When to use: The user asks 'tell me about project X' or an agent needs project metadata (start/end dates, type, Forma/BIM 360 flavor) before deciding which downstream tool to call.
When NOT to use: Do not use as a cheap existence check — prefer acc_list_projects which returns hub_id with every project and is one call regardless of tenant size.
APS scopes: data:read account:read. Forma / BIM 360 hubs endpoints only require data:read.
Rate limits: APS default ~50 req/min per endpoint; BIM 360 hubs endpoints pageable (limit 200). Cache results for the session.
Errors: 401 (APS token expired — refresh); 403 (user lacks project view or app not in account); 404 (project not in the chosen hub — supply the correct hub_id, or call acc_list_projects first); 422 (malformed project_id — confirm 'b.' prefix); 429 (rate limit — back off 60s); 5xx (ACC upstream — retry).
Side effects: None. Read-only and idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| hub_id | No | Optional ACC/BIM 360 hub ID. Also uses the 'b.' prefix literal. If omitted, the first hub returned by APS is used — prefer supplying this explicitly on multi-hub tenants to avoid 404s. | |
| project_id | Yes | ACC project ID. MUST use 'b.' prefix literal (this endpoint — unlike Issues/RFIs — wants the prefixed form). Obtain via acc_list_projects. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully covers behavior: read-only, idempotent, no side effects, rate limits (50 req/min), specific error codes with handling advice (401 refresh, 403 permissions, 404 hub mismatch, 422 malformed ID, 429 backoff, 5xx retry), and caching recommendation.
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 relatively long but well-structured with clear sections (when to use, when not, scopes, rate limits, errors, side effects). Every sentence adds value; no fluff. Could be slightly trimmed but content justifies length.
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 describes the return value as 'full ACC project metadata record' with example fields. It also covers error handling, rate limits, and usage patterns. For a simple read-only tool with 2 parameters, this is very complete.
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 extra context: hub_id optional but recommended for multi-hub tenants, project_id must have 'b.' prefix, and how to obtain them via acc_list_projects. This adds meaning beyond the 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?
The description clearly states the tool fetches the full ACC project metadata record for a single project, naming specific fields (name, type, status, dates, extension attributes). It distinguishes from siblings like acc_list_projects, which lists projects, by focusing on a single project's detailed metadata.
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 provide clear context: use for project metadata queries, not as a cheap existence check (prefer acc_list_projects). Also advises on hub_id omission risks and when to call acc_list_projects first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acc_search_documentsAInspect
Full-text search the ACC Docs repository of a project for drawings, specs, submittals, and other files via the APS Data Management search endpoint.
When to use: The user wants to find a document by keyword (filename, sheet number, or metadata match). E.g. 'find the latest A-201 sheet' or 'search for mechanical specs on Tower project'.
When NOT to use: Do not use to upload a file (use acc_upload_file); do not use to fetch issues/RFIs. If you already have a document URN, fetch it directly with an agent that has Data Management folder/item access.
APS scopes: data:read account:read. No write scope required.
Rate limits: APS Data Management ~50 req/min per app per endpoint; pageable (limit 200 upstream). Avoid tight query loops.
Errors: 401 (APS token expired — refresh); 403 (user lacks Docs view permission on the project); 404 (project_id not found — verify 'b.' prefix and hub membership); 422 (invalid filter syntax — simplify query text); 429 (rate limit — back off 60s); 5xx (ACC upstream — retry with jitter).
Side effects: None. Read-only and idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text search string matched against filenames, titles, and indexed metadata. 1–500 chars. | |
| project_id | Yes | ACC project ID. MUST use 'b.' prefix literal. The worker re-adds the prefix for Data Management URL formatting. Obtain via acc_list_projects. | |
| document_type | No | Optional APS document type filter (e.g. 'items:autodesk.bim360:File', 'items:autodesk.bim360:Document'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavioral traits: read-only and idempotent nature, required APS scopes, rate limits, and detailed error codes. This exceeds the burden typically carried by descriptions without annotations.
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?
Description is concisely structured with clear sections (purpose, when to use/not use, scopes, rate limits, errors, side effects). Every sentence adds value, front-loaded with purpose. 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 the tool's complexity (search with multiple parameters, error handling, rate limits), the description covers all necessary aspects for correct invocation. While no output schema is provided, the return values are predictable for a search endpoint.
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?
All three parameters have schema descriptions (100% coverage). The description adds meaningful context: query examples, project_id prefix requirement, and document_type filter usage. Enhances schema details but does not fundamentally transform comprehension.
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 performs full-text search on ACC Docs repository for drawings, specs, submittals, and other files. It uses specific verbs and resources, and distinguishes from sibling tools like acc_upload_file and issue/RFI tools.
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?
Provides explicit 'When to use' and 'When NOT to use' sections, including examples and alternatives. Clearly states when to avoid using this tool and directs to appropriate alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acc_update_issueAInspect
Patch an existing ACC issue — change status, priority, assignee, or description via the APS Construction Issues API.
When to use: The user asks to close/reopen/escalate an issue, reassign it, or edit its body. Typical agent flow: acc_list_issues → pick an id → acc_update_issue.
When NOT to use: Do not use to create issues (acc_create_issue) or to add comments (not supported by this server).
APS scopes: data:read data:write account:read.
Rate limits: ACC Issues API ~100 req/min per app; APS default ~50 req/min per endpoint.
Errors: 401 (APS token expired — refresh); 403 (user lacks edit permission or status transition not allowed by project workflow); 404 (project_id or issue_id not found — verify 'b.' prefix on project_id and that issue_id belongs to that project); 422 (validation — invalid status/priority enum or illegal state transition); 429 (rate limit — back off 60s); 5xx (ACC upstream — retry with jitter).
Side effects: Mutates the issue record. Idempotent when the same body is resent (PATCH semantics) — safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | New status. Project workflow may forbid certain transitions (e.g. draft → closed). | |
| issue_id | Yes | UUID of the issue to update, as returned by acc_list_issues or acc_create_issue. | |
| priority | No | New priority. | |
| project_id | Yes | ACC project ID. MUST use the 'b.' prefix literal. Obtain via acc_list_projects. | |
| assigned_to | No | APS user ID of the new assignee. Omit to leave unchanged. | |
| description | No | Replacement description body. Plain text. |
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 lists side effects (mutates record), idempotency (PATCH semantics), APS scopes (data:read data:write account:read), rate limits (~100 req/min per app), and detailed error codes with causes. This is comprehensive.
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 labeled sections (When to use, When NOT to use, APS scopes, Rate limits, Errors, Side effects). Every sentence serves a purpose without redundancy. It is concise yet thorough.
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 6 parameters, no output schema, and no annotations, the description covers all aspects: usage context, error handling, rate limits, idempotency, typical flow, and naming conventions (e.g., 'b.' prefix on project_id). It is fully sufficient for an agent to use 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 description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema's parameter descriptions; it only mentions the parameter names in the opening sentence. No extra context is provided for parameter values or constraints beyond what's already in the 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?
The description explicitly states 'Patch an existing ACC issue' and lists the updatable fields (status, priority, assignee, description). It distinguishes itself from siblings like acc_create_issue and acc_list_issues through the 'When NOT to use' section.
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?
Provides clear 'When to use' (user asks to close/reopen/escalate, reassign, or edit body) and 'When NOT to use' (do not use for creation or comments, with alternative tools). Also includes a typical agent flow (acc_list_issues → acc_update_issue).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acc_upload_fileAInspect
Upload a file from a public source URL into an ACC project folder. Runs the full four-step APS Data Management flow: top-folder discovery → storage object creation → OSS PUT of bytes → first-version item creation.
When to use: The user wants to push a document/photo/model into ACC Docs — e.g. 'upload this site photo to the Tower project Photos folder' or an automation needs to archive an exported report into Project Files.
When NOT to use: Do not use for files already in ACC; do not use for files behind auth-gated URLs (fetch step is an unauthenticated GET). For very large files (>100MB), prefer the chunked/signed-S3 upload flow, not this single-PUT implementation.
APS scopes: data:read data:write data:create account:read.
Rate limits: APS Data Management ~50 req/min per endpoint; OSS upload bandwidth typically 100 MB/min per app. This tool issues 3–5 APS calls per upload, so budget accordingly.
Errors: 401 (APS token expired — refresh); 403 (user lacks folder write permission — ask account admin to grant 'Edit' on folder); 404 (project_id not found or folder_path does not match any top folder — verify 'b.' prefix, hub membership, and folder name); 422 (invalid file_name or conflicting version); 429 (rate limit — back off 60s); 5xx (ACC/OSS upstream — retry with jitter BUT be cautious: storage object may already be created so reuse, do not re-create). Also: if source file_url returns non-2xx, the tool throws before touching ACC.
Side effects: Creates a storage object, uploads bytes, and creates a versioned item in the target folder. NOT idempotent — a retry may create a duplicate item with a new version. Surface the returned item_id to the user to avoid re-uploads.
| Name | Required | Description | Default |
|---|---|---|---|
| file_url | Yes | Publicly fetchable HTTPS URL of the source file. Must return 2xx to an unauthenticated GET. Max practical size ~100MB for this single-PUT implementation. | |
| file_name | Yes | Destination filename in ACC, including extension. 1–255 chars. Avoid path separators. | |
| project_id | Yes | ACC project ID. MUST use 'b.' prefix literal. Obtain via acc_list_projects. | |
| folder_path | No | Case-insensitive substring of the target top-level folder's display name. Defaults to 'Project Files'. Common values: 'Project Files', 'Plans', 'Photos', 'Submittals'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It covers APS scopes, rate limits, detailed error codes, side effects (non-idempotent duplicate creation), and preconditions (source file fetch). Nothing contradicts annotations.
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 (use, not use, scopes, limits, errors, side effects). Every sentence adds value. Front-loaded with main purpose. No waste.
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 tool with 4 parameters, no output schema, and no annotations, the description is remarkably thorough: covers purpose, usage, constraints, errors, side effects, rate limits. Mentions returning item_id, sufficient without output schema.
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 extra context beyond schema: file_url size limit and auth requirement, file_name character constraints, project_id prefix and derivation, folder_path defaults. Moderately enriches semantics.
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 uploads a file from a public URL into an ACC project folder, detailing the four-step APS flow. It distinguishes itself from sibling tools (issues, RFIs, projects) by focusing on file upload.
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 examples and alternatives (e.g., chunked upload for large files). Provides clear context for correct 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!