CareerProof MCP

atlas_get_jd_fit_results

Read-onlyIdempotent

Get JD-FIT results for a context. Returns ranked candidates with fit scores, strengths, and gaps. STRONGLY PREFER passing batch_id (from atlas_start_jd_fit_batch) to scope results to a single run — without it, the backend defaults to the latest batch only, which is usually what you want but may not match the user's intent if they want a specific earlier batch. Use include_all=true only when the user explicitly asks for full history across all batches. Free.

Input Schema

TableJSON Schema

Name	Required	Description
`sort_by`	No	Sort order. Default: score_desc.
`batch_id`	No	Scope results to a specific batch (from atlas_start_jd_fit_batch). Strongly recommended whenever you have a batch_id available — eliminates duplicates from historical runs.
`context_id`	Yes	Context ID from atlas_create_context or atlas_list_contexts
`include_all`	No	If true, return every historical JD-FIT analysis for this context (may include duplicates per candidate). Default false. Use only when user explicitly asks for full history.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedMay 17, 2026

addedInput schema / properties / batch_id

Added value: +{
+  "description": "Scope results to a specific batch (from atlas_start_jd_fit_batch). Strongly recommended whenever you have a batch_id available — eliminates duplicates from historical runs.",
+  "type": "number"
+}

addedInput schema / properties / include_all

Added value: +{
+  "description": "If true, return every historical JD-FIT analysis for this context (may include duplicates per candidate). Default false. Use only when user explicitly asks for full history.",
+  "type": "boolean"
+}

addedInput schema / properties / sort_by

Added value: +{
+  "description": "Sort order. Default: score_desc.",
+  "enum": [
+    "score_desc",
+    "score_asc"
+  ],
+  "type": "string"
+}

First observedMar 30, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by explaining default behavior (without batch_id, defaults to latest batch) and warning about duplicates with include_all. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (~120 words, 4 sentences) and front-loaded with purpose. The stray 'Free.' at the end is unnecessary but doesn't detract significantly. Information is well-structured: purpose, recommendation, default behavior, condition.

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

Completeness3/5

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

The description explains the return type at a high level (ranked candidates with scores, strengths, gaps) but lacks details about output structure (e.g., pagination, exact fields). Given no output schema, more detail would improve completeness. For a retrieval tool, it is adequate but not exhaustive.

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?

Schema description coverage is 100% (all 4 parameters have descriptions), baseline 3. The description adds extra context: preference for batch_id, what include_all does, and that sort_by defaults to score_desc. This goes beyond what the schema provides.

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), the resource (JD-FIT results), and the output (ranked candidates with fit scores, strengths, gaps). It distinguishes from sibling tools like atlas_get_jd_fit_batch_status (status vs. results) and atlas_start_jd_fit_batch (starting vs. retrieving).

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?

The description provides explicit guidance: strongly prefer passing batch_id, use include_all=true only when full history is explicitly requested. It explains default behavior (latest batch) and potential mismatch. However, it does not explicitly state prerequisites (e.g., batch must be complete) or when to use alternative tools.

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

All CareerProof MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?