Skip to main content
Glama

ACC MCP

by io.scanbimlabs

acc_search_documents

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesFree-text search string matched against filenames, titles, and indexed metadata. 1–500 chars.
project_idYesACC project ID. MUST use 'b.' prefix literal. The worker re-adds the prefix for Data Management URL formatting. Obtain via acc_list_projects.
document_typeNoOptional APS document type filter (e.g. 'items:autodesk.bim360:File', 'items:autodesk.bim360:Document').

TDQS

A4.6/5.0
Behavior5/5

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Side effects: None. Read-only and idempotent.', discloses required scopes ('data:read account:read, no write scope required'), rate limits (~50 req/min, pageable limit 200), and enumerates error codes with specific mitigation actions (401 refresh, 403 permission, 404 project ID checks, 422 simplify syntax, 429 back off 60s, 5xx retry with jitter). This comprehensive transparency goes well beyond a minimal description.

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 well-structured with labeled sections (When to use, When NOT to use, APS scopes, Rate limits, Errors, Side effects) and front-loaded with the core purpose in the first sentence. Every section provides actionable information without filler, making it scannable despite its length.

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

Completeness4/5

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

The description covers purpose, usage, exclusions, scopes, rate limits, error handling, and side effects, which is remarkably thorough. However, it omits any description of the response format (e.g., what fields are returned for matching documents), which is significant given that no output schema is provided. This prevents it from being fully complete.

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 input schema has 100% coverage with descriptions and examples for all three parameters, so the baseline is 3. The description adds general context about file types (drawings, specs, submittals) and usage examples, but the schema already covers parameter-specific details like the 'b.' prefix requirement for project_id and query matching semantics. The added value is marginal.

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

Purpose5/5

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

The description opens with 'Full-text search the ACC Docs repository of a project for drawings, specs, submittals, and other files via the APS Data Management search endpoint,' which clearly defines the verb (search), resource (ACC Docs repository), and scope. The 'When NOT to use' section explicitly names sibling tools like acc_upload_file and issue/RFI tools, distinguishing this tool from alternatives.

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 devotes dedicated 'When to use' and 'When NOT to use' sections with concrete examples ('find the latest A-201 sheet') and explicit alternatives ('do not use to upload a file (use acc_upload_file); do not use to fetch issues/RFIs'). This provides clear decision boundaries and direct tool differentiation.

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

All ACC MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources