CareerProof MCP

careerproof_task_result

Read-onlyIdempotent

Result of a completed background task. resource_id by result_type: analysis, fit_match, fit_rank: analysis_id; batch_gem: job_id; report: report_id; custom_eval_inference: model_id; custom_eval_batch: batch_id; dialogue_assessment: session_id. jd_fit_batch takes context_id (and batch_id) instead. Free.

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": {
      "task_id": "<task_id>",
      "result_type": "<result_type>"
    },
    "name": "careerproof_task_result"
  }
}

Input Schema

Name	Required	Description
`task_id`	Yes
`batch_id`	No	For jd_fit_batch: only that run (recommended)
`context_id`	No	For jd_fit_batch
`resource_id`	No
`result_type`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 11, 2026

changedInput schema / properties / batch_id / description

Previous value: -"For result_type='jd_fit_batch': scope results to a specific batch (from atlas_start_jd_fit_batch). Strongly recommended — eliminates duplicates from historical runs in the same context."New value: +"For jd_fit_batch: only that run (recommended)"

changedInput schema / properties / context_id / description

Previous value: -"Context ID (required for 'jd_fit_batch' results, from atlas_list_contexts)"New value: +"For jd_fit_batch"

removedInput schema / properties / resource_id / description

Removed value: -"Resource-specific ID: analysis_id for 'analysis'/'fit_match'/'fit_rank', job_id for 'batch_gem', report_id for 'report', model_id for 'custom_eval_inference', batch_id for 'custom_eval_batch', session_id for 'dialogue_assessment'"

removedInput schema / properties / result_type / description

Removed value: -"Type of result to fetch (determines the backend endpoint used)"

removedInput schema / properties / task_id / description

Removed value: -"The task_id of a completed async task"

Changed1 schema field changedMay 17, 2026

addedInput schema / properties / batch_id

Added value: +{
+  "description": "For result_type='jd_fit_batch': scope results to a specific batch (from atlas_start_jd_fit_batch). Strongly recommended — eliminates duplicates from historical runs in the same context.",
+  "type": "number"
+}

First observedMar 30, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new context: that the call is free, and that the correct id parameter varies by result_type. It does not say how incomplete or failed tasks are reported.

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?

Front-loaded with the one-line purpose, then a dense but scannable mapping list, then the exception and the cost note. The telegraphic semicolon style is efficient, though the mapping would read faster as a list than as a run-on clause.

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?

With five parameters, an enum and no output schema, the definition covers input selection well but leaves the return shape entirely undescribed, along with failure behavior for unfinished tasks. An agent knows how to call it but not what it will receive.

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 coverage is only 40%, so the description must compensate, and it does: it enumerates which id field to supply for each of the nine result_type values and calls out the jd_fit_batch exception (context_id plus batch_id). task_id itself is left unexplained, but the hard part, the id/type mapping, is fully covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource: the result payload of a completed background task, plus a per-result_type mapping of what resource_id means. It is clearly a fetch/retrieve operation and distinct in kind from careerproof_task_status, though it never names that sibling or states the 'only after completion' condition explicitly.

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 phrase 'Result of a completed background task' implies usage after completion, and 'Free' tells the agent there is no credit cost. But there is no explicit when-to-use versus careerproof_task_status or careerproof_wait, and no statement of what happens if the task is not yet finished.

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?