Skip to main content
Glama

aps_issues_get

Retrieve complete details for a specific issue, including its status, assignee, dates, location, custom attributes, linked documents, and permitted status transitions.

Instructions

Get detailed information about a single issue. Returns a compact summary with: id, title, description, status, assignee, dates, location, custom attributes, linked document count, permitted statuses, and more.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesProject ID – accepts with or without 'b.' prefix.
issue_idYesIssue UUID. Get this from aps_issues_list.
regionNoData centre region. Defaults to US.

Implementation Reference

  • src/index.ts:531-557 (registration)
    Tool registration for aps_issues_get: defines the tool name 'aps_issues_get', description, and inputSchema requiring project_id and issue_id (with optional region).
    // 13 ── aps_issues_get
    {
      name: "aps_issues_get",
      description:
        "Get detailed information about a single issue. " +
        "Returns a compact summary with: id, title, description, status, assignee, dates, location, " +
        "custom attributes, linked document count, permitted statuses, and more.",
      inputSchema: {
        type: "object" as const,
        properties: {
          project_id: {
            type: "string",
            description: "Project ID – accepts with or without 'b.' prefix.",
          },
          issue_id: {
            type: "string",
            description: "Issue UUID. Get this from aps_issues_list.",
          },
          region: {
            type: "string",
            enum: ["US", "EMEA", "AUS", "CAN", "DEU", "IND", "JPN", "GBR"],
            description: "Data centre region. Defaults to US.",
          },
        },
        required: ["project_id", "issue_id"],
      },
    },
  • Handler for aps_issues_get: validates project ID and issue ID, converts project ID (strips 'b.' prefix), makes GET request to construction/issues/v1/projects/{pid}/issues/{issueId}, and returns the summarized issue detail.
    // ── aps_issues_get ──────────────────────────────────────────
    if (name === "aps_issues_get") {
      const projectId = args.project_id as string;
      const issueId = args.issue_id as string;
      const e1 = validateIssuesProjectId(projectId);
      if (e1) return fail(e1);
      const e2 = validateIssueId(issueId);
      if (e2) return fail(e2);
    
      const pid = toIssuesProjectId(projectId);
      const region = args.region as string | undefined;
      const t = await token();
    
      const raw = await apsDmRequest(
        "GET",
        `construction/issues/v1/projects/${pid}/issues/${issueId}`,
        t,
        { headers: issuesHeaders(region) },
      );
      return json(summarizeIssueDetail(raw));
    }
  • summarizeIssueDetail helper: transforms raw API response into a compact IssueDetailSummary with fields like id, title, description, status, assignee, dates, custom attributes, linked document count, watchers, and permitted statuses.
    export function summarizeIssueDetail(raw: unknown): IssueDetailSummary {
      const issue = raw as Record<string, unknown>;
    
      const customAttrs = Array.isArray(issue.customAttributes)
        ? (issue.customAttributes as Record<string, unknown>[]).map((ca) => ({
            id: (ca.attributeDefinitionId as string) ?? "",
            value: ca.value,
            type: (ca.type as string) ?? undefined,
            title: (ca.title as string) ?? undefined,
          }))
        : undefined;
    
      const linkedDocs = Array.isArray(issue.linkedDocuments)
        ? issue.linkedDocuments.length
        : 0;
    
      return {
        id: issue.id as string,
        displayId: (issue.displayId as number) ?? 0,
        title: (issue.title as string) ?? "",
        description: (issue.description as string) ?? undefined,
        status: (issue.status as string) ?? "",
        issueTypeId: (issue.issueTypeId as string) ?? undefined,
        issueSubtypeId: (issue.issueSubtypeId as string) ?? undefined,
        assignedTo: (issue.assignedTo as string) ?? undefined,
        assignedToType: (issue.assignedToType as string) ?? undefined,
        dueDate: (issue.dueDate as string) ?? undefined,
        startDate: (issue.startDate as string) ?? undefined,
        locationId: (issue.locationId as string) ?? undefined,
        locationDetails: (issue.locationDetails as string) ?? undefined,
        rootCauseId: (issue.rootCauseId as string) ?? undefined,
        published: (issue.published as boolean) ?? false,
        commentCount: (issue.commentCount as number) ?? 0,
        createdBy: (issue.createdBy as string) ?? "",
        createdAt: (issue.createdAt as string) ?? "",
        updatedAt: (issue.updatedAt as string) ?? "",
        closedBy: (issue.closedBy as string) ?? undefined,
        closedAt: (issue.closedAt as string) ?? undefined,
        customAttributes: customAttrs,
        linkedDocumentCount: linkedDocs,
        watchers: Array.isArray(issue.watchers)
          ? (issue.watchers as string[])
          : undefined,
        permittedStatuses: Array.isArray(issue.permittedStatuses)
          ? (issue.permittedStatuses as string[])
          : undefined,
      };
    }
  • toIssuesProjectId helper: strips the 'b.' prefix from a Data Management project ID for use with the Issues API.
    export function toIssuesProjectId(projectId: string): string {
      return projectId.replace(/^b\./, "");
    }
  • validateIssueId helper: validates that the issue_id parameter is non-empty.
    export function validateIssueId(id: string): string | null {
      if (!id) return "issue_id is required.";
      return null;
    }
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does not explicitly state that the tool is read-only or safe, though the name 'get' implies no side effects. The description adds value by listing the return fields, but lacks details on permissions or error behavior. A 3 is appropriate as it adds some context but not comprehensive behavioral disclosure.

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 a single efficient sentence that front-loads the core action ('Get detailed information') and then lists key return fields. No unnecessary words or repetition. It is perfectly concise and well-structured.

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 no output schema and no annotations, the description is fairly complete. It specifies the purpose, identifies the returned fields, and the input schema (through parameter descriptions) hints that issue_id comes from aps_issues_list. It lacks error handling or rate limit info, but for a simple read tool, this is adequate. A 4 reflects good but not exhaustive 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 baseline is 3. The description does not add new information about parameters beyond the schema (e.g., project_id, issue_id, region). The main description lists return fields, which is helpful but not directly about parameters. Hence, a 3 is correct.

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: 'Get detailed information about a single issue.' It specifies the verb (get) and resource (issue), and the scope (single), which distinguishes it from sibling tools like aps_issues_list (list multiple issues) and aps_issues_get_comments (get comments). The return fields are enumerated, leaving no ambiguity about what the tool does.

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

Usage Guidelines3/5

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

No explicit guidance is given on when to use this tool versus alternatives. The context is implied by the input schema requiring an issue_id (suggesting it is for a single issue), but the description does not mention when to use aps_issues_list instead or provide exclusions. Thus, usage is implied but not explicit.

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