FoundRole Jobs - AI Job Search & Application Tracker

Official

by foundrole

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Search career guides

knowledge_search

Read-onlyIdempotent

Search FoundRole's career articles and site pages by semantic similarity to answer job-search questions, returning relevant sources with titles, URLs, and excerpts.

Instructions

Searches FoundRole's published content by semantic similarity and returns the most relevant sources for a job-search question: career-guidance blog articles plus FoundRole site pages that describe the product's features (job tracker, Pro plan and pricing, H1B salary data, AI job search) and industry/sector career landings. Each article carries a title, url, summary, a content excerpt, publication date, and tags; each page carries a title, url, description, and its FAQ entries — enough material to answer the question and link the source.

Two optional facets add further result groups: company returns FoundRole's employer profile pages matching that company name; location returns the market landing page for that city, state, or country — an analytical page about that labour market, not a list of openings. The facets describe what the user is asking about — a company mentioned only in passing does not need the company facet.

Returns empty groups when nothing is relevant rather than padding with off-topic content. Results are the closest matches to the given question, not an index of the site's full coverage; questions about overall topic coverage are answered by knowledge_topics, which lists the blog's categories and tags with article counts. It does not search job listings and reports no open-job counts — jobs_search covers live roles, including questions about openings for a particular job title. Each response includes a system_instruction describing how to present the sources.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum articles to return (default 5)
`query`	Yes	The career, job-search, or FoundRole product question to answer
`company`	No	A company name, when the question is about that employer — returns FoundRole company profile pages
`location`	No	A city, state, or country, when the question is about that labour market — returns its market landing page

Output Schema

TableJSON Schema

Name	Required	Description	Default
`pages`	No
`proUrl`	No
`articles`	No
`totalCount`	No
`companyPages`	No
`landingPages`	No
`profileSetupUrl`	No
`system_instruction`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.1.16Sep 27, 2026

removedInput schema / properties / job_title

Removed value: -{
-  "description": "A job title or role, when the question is about openings for it — returns job-listing landing pages",
-  "type": "string"
-}

changedInput schema / properties / location / description

Previous value: -"A city, state, or country refining job_title, or alone when the question is about jobs in that place"New value: +"A city, state, or country, when the question is about that labour market — returns its market landing page"

removedOutput schema / properties / companyPages / items / properties / openJobs
```
Removed value: -{
-  "type": [
-    "integer",
-    "null"
-  ]
-}
```
removedOutput schema / properties / landingPages / items / properties / openJobs
```
Removed value: -{
-  "type": [
-    "integer",
-    "null"
-  ]
-}
```

First observedv1.1.9Aug 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld=false), so the description's job is added context — and it delivers: empty groups rather than padded off-topic results, closest-match (non-exhaustive) semantics, facet behavior, and a system_instruction included in each response. It does not mention pagination or rate limits, but nothing essential is missing.

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 core operation, then facets, then boundaries with siblings. It is on the long side and some enumeration of site-page types (Pro plan, H1B salary data, AI job search) borders on padding, but nearly every sentence carries routing or behavioral information.

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?

An output schema exists, and the description correctly refrains from re-explaining return values while still flagging the embedded system_instruction and the empty-group behavior. Combined with clear sibling boundaries and facet disambiguation, an agent has everything needed to select and invoke it correctly.

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 100%, so baseline is 3, but the description adds genuine meaning beyond it: 'company' maps to employer profile pages and 'location' maps to an analytical market landing page, not job listings, plus the disambiguation rule that a company mentioned in passing does not need the facet. That goes past restating schema text.

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 precise verb+resource ('Searches FoundRole's published content by semantic similarity') and enumerates the corpora searched (blog articles, product/site pages, sector landings). It explicitly distinguishes itself from siblings jobs_search and knowledge_topics, so an agent can route without opening any 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?

Names the alternatives and the conditions that select them: 'questions about overall topic coverage are answered by knowledge_topics' and 'It does not search job listings... jobs_search covers live roles'. It also gives a when-not for the optional facets ('a company mentioned only in passing does not need the company facet'). This is explicit when/when-not/alternative guidance.

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