Skip to main content
Glama

ACC MCP

by io.scanbimlabs

acc_create_issue

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesShort issue title, 1–255 chars. Required.
due_dateNoOptional due date in ISO 8601 date format (YYYY-MM-DD).
priorityNoIssue priority. Defaults to 'medium' if omitted.
project_idYesACC 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_toNoOptional APS user ID (oxygen ID / ACC user UUID) of the assignee. Leave null for unassigned.
descriptionYesDetailed issue description / body. Plain text, up to ~10,000 chars. Required.

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses side effects (persistent issue record), idempotency (NOT idempotent, dedupe by title), rate limits, and detailed error semantics (401, 403, 404, 422, 429, 5xx). This is comprehensive and goes beyond basic expectations.

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 clear headers (When to use, When NOT to use, APS scopes, Rate limits, Errors, Side effects). Every sentence provides actionable information; it is long but not bloated, and the front-loaded purpose ensures the agent immediately knows what the tool does.

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 tool has no output schema, so the description should ideally cover return behavior. It comprehensively covers authentication, rate limits, error handling, and side effects, but does not explicitly state what the API returns (e.g., created issue ID). This is a minor gap given the otherwise rich context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers 100% of parameters with examples and descriptions, so baseline is 3. The description adds extra value by clarifying the 'b.' prefix requirement for project_id and noting that the worker strips it internally, which is not in 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 starts with a specific verb ('Create a new ACC issue') and identifies the resource and API. It also lists example issue types, distinguishing it from siblings like acc_create_rfi and acc_update_issue.

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 includes explicit 'When to use' and 'When NOT to use' sections, with concrete examples and named alternatives (acc_update_issue for modifications, acc_create_rfi for RFIs). This leaves no ambiguity about when the tool should be selected.

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