Skip to main content
Glama
Sign In
CodebaseAgent-MCP

CodebaseAgent-MCP

by FI-Mihej
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

codebase_get_job_result

Retrieve the final result, error, or latest partial output for a codebase analysis job after its status reaches success or failure.

Instructions

Return the final result, error, or latest partial output for an analysis job. You must poll using codebase_get_job_status tool until success/failure. This tool internally waits up to 50s/request. Avoid assuming failure before terminal status. You are forbidden to finish response while polling is running.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "job_id": "<job_id>"
    },
    "name": "codebase_get_job_result"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idYesJob id returned by either `codebase_start_job_related_files_search` or `codebase_start_job_analysis`.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Discloses significant behavioral traits: internal wait up to 50s, dependency on prior status polling, and a rule against finalizing during polling. However, there is minor ambiguity: mentioning 'latest partial output' suggests it may be called before terminal status, while the instruction to poll until success/failure implies it should not be. This slight inconsistency prevents a perfect score.

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 four sentences, each earning its place: purpose first, then crucial usage rules and warnings. It is well-structured, front-loaded, and free of fluff.

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?

For a complex tool with no annotations, the description covers the essential context: polling sequence, wait behavior, failure handling, and a hard rule about not finalizing responses. The minor ambiguity about partial output versus terminal polling keeps it from being fully complete, but it is otherwise thorough.

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?

The only parameter, job_id, has 100% schema description coverage and is fully explained in the schema as the id returned by the start job tools. The description adds no extra semantics beyond the schema, so baseline 3 applies.

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 uses a specific verb+resource ('Return the final result, error, or latest partial output for an analysis job') that clearly distinguishes it from sibling tools like codebase_get_job_status (status) and codebase_start_job_* (starting jobs). It unambiguously states 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 Guidelines5/5

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

The description provides explicit when-to-use guidance: poll codebase_get_job_status until success/failure, then use this tool. It warns about the 50s internal wait, cautions against assuming failure before terminal status, and forbids finishing the response while polling is running. This is a complete workflow context.

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

Deploy Server

Other Tools