Skip to main content
Glama

cortex_get_job_artifacts

Retrieve extracted observables and IOCs from a completed analysis job by providing the job ID.

Instructions

Get artifacts (extracted observables/IOCs) from a completed analysis job

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobIdYesThe job ID to get artifacts for

Implementation Reference

  • MCP tool handler that receives a jobId, calls client.getJobArtifacts(), and returns the artifacts as JSON string in the response content.
    server.tool(
      "cortex_get_job_artifacts",
      "Get artifacts (extracted observables/IOCs) from a completed analysis job",
      {
        jobId: z.string().describe("The job ID to get artifacts for"),
      },
      async ({ jobId }) => {
        try {
          const artifacts = await client.getJobArtifacts(jobId);
          return {
            content: [
              {
                type: "text" as const,
                text: JSON.stringify(artifacts, null, 2),
              },
            ],
          };
        } catch (error) {
          return {
            content: [
              {
                type: "text" as const,
                text: `Error getting job artifacts: ${error instanceof Error ? error.message : String(error)}`,
              },
            ],
            isError: true,
          };
        }
      },
    );
  • Zod schema defining input: jobId (required string).
    {
      jobId: z.string().describe("The job ID to get artifacts for"),
    },
  • Tool registered on the server with the name 'cortex_get_job_artifacts' as part of registerJobTools().
    server.tool(
      "cortex_get_job_artifacts",
  • src/tools/jobs.ts:5-8 (registration)
    Function registerJobTools() exported from jobs.ts, called from index.ts to register all job-related tools including cortex_get_job_artifacts.
    export function registerJobTools(
      server: McpServer,
      client: CortexClient,
    ): void {
  • CortexClient helper method that performs GET request to /api/job/{jobId}/artifacts and returns an array of Artifact objects.
    async getJobArtifacts(jobId: string): Promise<Artifact[]> {
      return this.request<Artifact[]>(
        `/job/${encodeURIComponent(jobId)}/artifacts`,
      );
    }
Behavior2/5

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

No annotations are provided, so the description must carry full behavioral disclosure. It mentions the job must be 'completed' but does not specify error handling for incomplete jobs, invalid IDs, or what happens if no artifacts exist.

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 concise sentence that efficiently communicates the tool's purpose. Every word is meaningful, with no wasted language.

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 has one simple parameter, no output schema, and no annotations, the description covers the essential purpose and condition (completed job). Minor gaps remain about return value format or error cases, but overall it is relatively complete for a simple retrieval tool.

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% for the single parameter jobId, which is described as 'The job ID to get artifacts for'. The tool description adds no additional meaning beyond this schema field, so baseline 3 is appropriate.

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 action 'Get' and the resource 'artifacts (extracted observables/IOCs)' from a completed analysis job. It effectively distinguishes from sibling tools like cortex_get_job and cortex_get_job_report by specifying artifacts.

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?

The description implies usage after a job completes but lacks explicit when-to-use or when-not-to-use guidance. No alternative tools are mentioned, though context signals show siblings that could confuse an agent.

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/solomonneas/cortex-mcp'

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