Skip to main content
Glama

aps_docs

Return APS Data Management documentation covering ID formats, browsing workflow, API paths, query parameters, BIM file extensions, and error troubleshooting. Use before first APS interaction or when unsure about ID formats or API paths.

Instructions

Return APS Data Management quick‑reference documentation: common ID formats, typical browsing workflow, raw API paths, query parameters, BIM file extensions, and error troubleshooting. Call this before your first APS interaction or when unsure about ID formats or API paths.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The tool handler for 'aps_docs' – simply returns the APS_DOCS constant as the tool response.
    if (name === "aps_docs") {
      return ok(APS_DOCS);
    }
  • The tool registration / schema definition for 'aps_docs' – no input parameters needed.
    // 9 ── aps_docs
    {
      name: "aps_docs",
      description:
        "Return APS Data Management quick‑reference documentation: " +
        "common ID formats, typical browsing workflow, raw API paths, query parameters, " +
        "BIM file extensions, and error troubleshooting. " +
        "Call this before your first APS interaction or when unsure about ID formats or API paths.",
      inputSchema: { type: "object" as const, properties: {} },
    },
  • src/index.ts:362-371 (registration)
    The 'aps_docs' tool is registered in the TOOLS array (index 9). It's listed in the tool definitions along with other APS tools.
    // 9 ── aps_docs
    {
      name: "aps_docs",
      description:
        "Return APS Data Management quick‑reference documentation: " +
        "common ID formats, typical browsing workflow, raw API paths, query parameters, " +
        "BIM file extensions, and error troubleshooting. " +
        "Call this before your first APS interaction or when unsure about ID formats or API paths.",
      inputSchema: { type: "object" as const, properties: {} },
    },
  • The APS_DOCS constant is defined in aps-dm-helpers.ts (line 852–914). It contains the Markdown quick-reference documentation for APS Data Management.
    export const APS_DOCS = `# APS Data Management – Quick Reference
    
    ## Common ID Formats
    - **Hub ID**: \`b.<account_id>\` (e.g. \`b.abc12345-6789-…\`)
    - **Project ID**: \`b.<project_id>\` (same format as hub)
    - **Folder URN**: \`urn:adsk.wipprod:fs.folder:co.<id>\`
    - **Item URN (lineage)**: \`urn:adsk.wipprod:dm.lineage:<id>\`
    - **Version URN**: \`urn:adsk.wipprod:fs.file:vf.<id>?version=<n>\`
    
    ## Typical Browsing Workflow
    \`\`\`
    1. aps_list_hubs                                      → pick a hub
    2. aps_list_projects        hub_id                    → pick a project
    3. aps_get_top_folders      hub_id + project_id       → see root folders
    4. aps_get_folder_contents  project_id + folder_id    → browse files
    5. aps_get_item_details     project_id + item_id      → file metadata
    \`\`\`
    
    ## Raw API Paths (for aps_dm_request)
    | Action | Method | Path |
    |--------|--------|------|
    | List hubs | GET | project/v1/hubs |
    | List projects | GET | project/v1/hubs/{hub_id}/projects |
    | Top folders | GET | project/v1/hubs/{hub_id}/projects/{project_id}/topFolders |
    | Folder contents | GET | data/v1/projects/{project_id}/folders/{folder_id}/contents |
    | Item details | GET | data/v1/projects/{project_id}/items/{item_id} |
    | Item tip version | GET | data/v1/projects/{project_id}/items/{item_id}/tip |
    | All versions | GET | data/v1/projects/{project_id}/items/{item_id}/versions |
    | Search folder | GET | data/v1/projects/{project_id}/folders/{folder_id}/search |
    | Create folder | POST | data/v1/projects/{project_id}/folders |
    | Download | GET | (use storage URL from version relationships.storage.meta.link.href) |
    
    ## Query Parameters
    - \`page[number]\` – page index (0‑based)
    - \`page[limit]\` – items per page (default 25, max 200)
    - \`filter[type]\` – filter by resource type
    - \`filter[extension.type]\` – filter by extension type
    - \`includeHidden\` – include hidden items (default false)
    
    ## Common BIM File Extensions
    | Extension | Description |
    |-----------|-------------|
    | .rvt | Revit Model |
    | .rfa | Revit Family |
    | .nwd | Navisworks (full) |
    | .nwc | Navisworks Cache |
    | .ifc | Industry Foundation Classes |
    | .dwg | AutoCAD Drawing |
    | .dwfx | Design Web Format |
    | .pdf | PDF Document |
    
    ## Error Troubleshooting
    | Code | Common Cause | Fix |
    |------|-------------|-----|
    | 401 | Expired / invalid token | Check credentials; token auto‑refreshes |
    | 403 | App not provisioned | Admin → Account Settings → Custom Integrations |
    | 404 | Wrong ID format | Hub/project use 'b.' prefix; folders/items use 'urn:' |
    | 429 | Rate limited | Wait 60 s, reduce request frequency |
    
    ## Full Specification
    - Docs: https://aps.autodesk.com/en/docs/data/v2/reference/http/
    - OpenAPI: https://github.com/autodesk-platform-services/aps-sdk-openapi/blob/main/datamanagement/datamanagement.yaml
    `;
Behavior4/5

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

Describes what the documentation covers. No annotations provided, so description carries full burden. No behavioral contradictions; adequate for a read-only documentation 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?

Two sentences, front-loaded with purpose, no extraneous words. Highly efficient and well-structured.

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

Completeness5/5

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

Given no parameters, no output schema, and a simple documentation purpose, the description fully covers what the tool does and when to use it. Complete for its complexity.

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?

Input schema has no parameters (schema coverage 100%). Baseline 4 applies; description adds no param info but none needed.

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?

Clearly states it returns APS Data Management quick-reference documentation covering specific topics like ID formats, API paths, and troubleshooting. Distinguishes from sibling action tools by being a documentation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to call this before first APS interaction or when unsure about IDs or API paths. Provides clear context but does not explicitly list when not to use it or name alternative siblings.

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

Install Server

Other Tools

Latest Blog Posts

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/EverseDevelopment/APS.MCP'

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