CareerProof MCP

careerproof_task_status

Read-onlyIdempotent

Progress of a background task: status queued/processing/retrying/completed/failed (retrying = still running) and progress_pct; a failed task has error_code and credits_refunded. When completed, fetch the result with careerproof_task_result. To wait for it, prefer careerproof_wait(kind='task', id=task_id). 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>"
    },
    "name": "careerproof_task_status"
  }
}

Input Schema

Name	Required	Description	Default
`task_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	No
`status`	Yes
`task_id`	Yes
`error_code`	No
`analysis_id`	No
`progress_pct`	No
`credit_status`	No
`current_stage`	No
`error_message`	No
`credits_refunded`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026
- removedInput schema / properties / task_id / description
```
Removed value: -"The task_id returned by any async start tool"
```
Changed1 schema field changedNov 8, 2026
- addedOutput schema / properties / error_code
```
Added value: +{
+  "$ref": "#/properties/current_stage"
+}
```
Changed3 schema fields changedOct 5, 2026
- changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +true
```
- addedOutput schema / properties / credit_status
```
Added value: +{
+  "$ref": "#/properties/current_stage"
+}
```
- addedOutput schema / properties / credits_refunded
```
Added value: +{
+  "$ref": "#/properties/analysis_id"
+}
```
First observedMar 30, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare the safe read-only, idempotent profile, but the description adds genuinely new behavior: the meaning of 'retrying' (still running), the presence of error_code and credits_refunded on failure, and that the call is free. It stops short of noting polling cadence or whether terminal states are cached, which is why it is not a 5.

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?

Two dense sentences: status semantics first, routing guidance second, with the cost note appended. No filler, and the most decision-relevant facts are front-loaded.

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?

An output schema exists, yet the description still summarizes the key return fields, which is helpful rather than redundant. The only gap for a polling tool is the origin/format of task_id and any guidance on poll interval, neither of which is covered.

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 single task_id parameter has 0% schema description coverage, and the description only surfaces it incidentally inside the careerproof_wait example. It does not say where task_id comes from (presumably a prior submission) or its format, so meaning beyond the schema is minimal.

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?

States a specific resource (progress of a background task) and enumerates the exact status values plus progress_pct and failure fields. It is clearly distinguished from careerproof_task_result (fetching the result) and careerproof_wait (blocking), so an agent can pick it without opening a schema.

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?

Gives explicit routing: use this to poll progress, use careerproof_task_result when completed, and prefer careerproof_wait(kind='task', id=task_id) when blocking is desired. Both the when and the alternatives are named directly.

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?