FoundRole Jobs - AI Job Search & Application Tracker

Official

Overview Schema Source Related Servers Discussions Admin

Analyze a job from another site

jobs_analyze_external

Analyze external job postings against your FoundRole profile to assess resume match, missing skills, H-1B sponsorship, E-Verify, ghost-job risk, and salary estimates.

Instructions

Analyzes one job found outside FoundRole using the authenticated user's FoundRole profile and the same signals used for FoundRole jobs: resume match, missing skills, H-1B sponsorship history, E-Verify, ghost-job risk, posted compensation, and market salary estimates. Use tracker_add_external only when the user asks to save without analysis.

The input represents the direct posting URL and all job content already available in the conversation. The five text identity fields are required; every structured fact field is optional, with a fact the source does not state simply omitted (or null). The optional client_extraction object carries evidence-backed skills, technology, benefits, bonuses, seniority, industry, management, clearance, visa, and remote-scope labels when source excerpts for them exist. FoundRole validates the evidence, stores the client extraction separately, derives missing deterministic facts, and reports which values were provided, derived, accepted, rejected, or remain unknown.

The output includes comparisonRef; retain it exactly for a later jobs_compare call. The analysis is a decision aid, not a guarantee about sponsorship, legitimacy, compensation, or hiring outcome.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Direct URL of the specific job posting; a company homepage is invalid
`posted_at`	No	Posting date as ISO 8601, when the source states it
`title_name`	Yes	Job title from the posting
`description`	Yes	Complete posting text available in the conversation; a source summary is valid only when no fuller posting text is available
`salary_type`	No	Salary period: year, month, week, day, hour
`company_name`	Yes	Company name from the posting
`salary_value`	No	Single salary amount, when the posting gives one figure instead of a range
`location_name`	Yes	Location text from the posting, including Remote when stated
`employment_type`	No	Employment types: full_time, part_time, contractor, temporary, intern, volunteer, per_diem, other
`salary_currency`	No	ISO 4217 salary currency code, when stated
`salary_max_value`	No	Salary range maximum, when stated
`salary_min_value`	No	Salary range minimum, when stated
`client_extraction`	No	Evidence-backed facts extracted by the client model from the posting; non-null evidence is a short source excerpt rather than an inference. Fields absent from the source are omitted or null.
`experience_months`	No	Minimum required experience in months, when stated
`work_location_type`	No	Work arrangement: on_site, remote, hybrid
`education_requirements`	No	Education requirements: no_requirements, high_school, associate_degree, bachelor_degree, professional_certificate, postgraduate_degree

Output Schema

TableJSON Schema

Name	Required	Description	Default
`jobs`	Yes
`mode`	Yes
`studioUrl`	No
`statusOrder`	Yes
`derivedFields`	Yes
`trackerWebUrl`	Yes
`unknownFields`	Yes
`providedFields`	Yes
`clientExtraction`	Yes
`system_instruction`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.1.16Sep 27, 2026
- removedOutput schema / properties / jobs / items / properties / estimatedSalary / properties / basedOn
```
Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}
```
- addedOutput schema / properties / jobs / items / properties / estimatedSalary / properties / currency
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / studioUrl
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / system_instruction
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
First observedv1.1.9Aug 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false/destructiveHint=false/openWorldHint=false. The description goes well beyond that: it states what FoundRole does server-side (validates evidence, stores client extraction separately, derives missing deterministic facts, reports provided/derived/accepted/rejected/unknown), and candidly frames the analysis as a decision aid rather than a guarantee.

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 purpose is front-loaded and the routing instruction sits near the top where it matters. Three paragraphs is somewhat long and the middle paragraph is dense, but each block carries distinct information with little filler.

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

Completeness5/5

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

For a 16-parameter, output-schema-backed tool, the description covers the input contract conventions, the server-side validation semantics, the comparisonRef handoff, and the limits of the result. Nothing an agent needs to invoke it correctly is missing.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: the five text identity fields are required while every structured fact is optional and simply omitted/null when the source is silent, and client_extraction labels must be evidence-backed. These rules are not obvious from the schema alone.

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 opening sentence gives a specific verb and resource ('Analyzes one job found outside FoundRole') and enumerates the exact signals computed (resume match, missing skills, H-1B history, E-Verify, ghost-job risk, compensation, market salary). It is clearly distinguishable from sibling tools like jobs_details and tracker_add_external.

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?

It routes the agent explicitly away from this tool in one case ('Use tracker_add_external only when the user asks to save without analysis') and forward to jobs_compare via comparisonRef. That is real when/when-not guidance, though it doesn't differentiate from jobs_details or jobs_search.

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