Skip to main content
Glama

aps_dm_request

Call APS Data Management API endpoints directly for full control over projects, hubs, and folders. Use for pagination, POST/PATCH/DELETE operations, or accessing endpoints not covered by simplified tools.

Instructions

Call any APS Data Management API endpoint (project/v1, data/v1). This is the raw / power‑user tool – it returns the full JSON:API response which can be very large (100 K+ tokens for folder listings). Prefer the simplified tools (aps_list_hubs, aps_list_projects, aps_get_folder_contents, etc.) for everyday browsing. Use this tool when you need full control: pagination, POST/PATCH/DELETE, or endpoints not covered by simplified tools.

Response guidance – when summarising large responses focus on: • Folders: name, id, item count • Files: name, type/extension, size, last modified, version info • Ignore: relationship links, JSON:API meta, and extended attributes unless specifically needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodYesHTTP method.
pathYesAPI path relative to developer.api.autodesk.com (e.g. 'project/v1/hubs' or 'data/v1/projects/b.xxx/folders/urn:adsk.wipprod:fs.folder:co.xxx/contents'). Must include the version prefix (project/v1 or data/v1).
queryNoOptional query parameters as key/value pairs (e.g. { "page[limit]": "200", "includeHidden": "true" }).
bodyNoOptional JSON body for POST/PATCH requests.

Implementation Reference

  • The implementation of apsDmRequest which handles HTTP requests to the APS Data Management API.
    export async function apsDmRequest(
      method: ApsDmMethod,
      path: string,
      token: string,
      options: ApsDmRequestOptions = {}
    ): Promise<unknown> {
      const isAbsolute = path.startsWith("http");
      if (isAbsolute) {
        const target = new URL(path);
        const allowed = new URL(APS_BASE);
        if (target.host !== allowed.host) {
          throw new Error(
            `Refusing to send APS token to foreign host '${target.host}'. ` +
            `Only requests to '${allowed.host}' are allowed. Use a relative path instead.`,
          );
        }
      }
      const normalized = isAbsolute ? path : path.replace(/^\//, "");
      const url = new URL(isAbsolute ? normalized : `${APS_BASE}/${normalized}`);
    
      if (options.query) {
        for (const [k, v] of Object.entries(options.query)) {
          if (v === undefined) continue;
          if (Array.isArray(v)) {
            v.forEach((val) => url.searchParams.append(k, String(val)));
          } else {
            url.searchParams.set(k, String(v));
          }
        }
      }
    
      const headers: Record<string, string> = {
        Authorization: `Bearer ${token}`,
        ...options.headers,
      };
      if ((method === "POST" || method === "PATCH") && options.body !== undefined) {
        headers["Content-Type"] = headers["Content-Type"] ?? "application/vnd.api+json";
      }
    
      const init: RequestInit = { method, headers };
      if (options.body !== undefined && (method === "POST" || method === "PATCH")) {
        init.body = JSON.stringify(options.body);
      }
    
      const res = await fetch(url.toString(), init);
      if (!res.ok) {
        const text = await res.text();
        throw new ApsApiError(res.status, method, url.pathname, text);
      }
      if (res.status === 204) {
        return { ok: true, status: 204 };
      }
      const text = await res.text();
      if (!text) {
        return { ok: true, status: res.status };
      }
      const ct = (res.headers.get("content-type") ?? "").toLowerCase();
      if (ct.includes("json")) {
        try {
          return JSON.parse(text);
  • Type definition for the options allowed in an apsDmRequest call.
    export interface ApsDmRequestOptions {
      /** Query parameters (e.g. page[number], filter[type]). */
      query?: Record<string, string | number | boolean | string[] | undefined>;
      /** Request body for POST/PATCH (JSON). */
      body?: unknown;
      /** Extra headers (e.g. x-user-id, Content-Type). */
      headers?: Record<string, string>;
    }
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it returns 'full JSON:API response which can be very large (100 K+ tokens for folder listings),' warns about response size, and provides response guidance for summarization. However, it lacks details on authentication needs, rate limits, or error handling, which are important for a raw API 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?

The description is well-structured and front-loaded with the core purpose, followed by usage guidelines and response advice. Every sentence adds value: the first defines the tool, the second contrasts with siblings, the third specifies use cases, and the last provides summarization tips. No wasted words.

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?

Given the tool's complexity (raw API access with 4 parameters, no output schema, and no annotations), the description does a good job covering purpose, usage, and behavioral aspects like response size. However, it lacks details on authentication, error responses, or output structure, which are critical for a power-user tool, leaving some gaps in completeness.

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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no specific parameter semantics beyond implying the tool's flexibility with endpoints and methods. It meets the baseline of 3 by not duplicating schema info but doesn't enhance parameter understanding significantly.

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 clearly states the tool's purpose: 'Call any APS Data Management API endpoint (project/v1, data/v1).' It specifies the exact API scope and distinguishes it from simplified sibling tools by labeling it as a 'raw / power‑user tool' that returns full JSON:API responses, making its role explicit and differentiated.

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 provides explicit guidance on when to use this tool versus alternatives: 'Prefer the simplified tools... for everyday browsing. Use this tool when you need full control: pagination, POST/PATCH/DELETE, or endpoints not covered by simplified tools.' It clearly defines use cases and exclusions, helping the agent choose appropriately.

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

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