LinkBridge MCP

Search Jobs

search_jobs

Read-only

Search LinkedIn job listings by keywords, location, date posted, job type, experience level, and work type, then return job IDs to pass to get_job_details for full posting info.

Instructions

Search for jobs on LinkedIn.

Returns job_ids that can be passed to get_job_details for full info.

LinkedIn is moving accounts to a redesigned job search, which keeps only the keywords, date_posted and paging. It drops the filters marked "Classic search only" and reports them in section_errors as filters_dropped. When it drops the location or work type, search again with them in the keywords ("remote python developer in Lyon") and keep doing so; words such as "senior" or "internship" there narrow the results too. Quotes do not make a phrase exact on that search.

Input Schema

Name	Required	Description
`sort_by`	No	Sort results (date, relevance). Classic search only.
`job_type`	No	Filter by job type, comma-separated (full_time, part_time, contract, temporary, volunteer, internship, other). Classic search only.
`keywords`	Yes	Search keywords (e.g., "software engineer", "data scientist")
`location`	No	Optional location filter (e.g., "San Francisco", "Remote"). Classic search only.
`max_pages`	No	Maximum number of result pages to load (1-10, default 3)
`work_type`	No	Filter by work type, comma-separated (on_site, remote, hybrid). Classic search only.
`easy_apply`	No	Only show Easy Apply jobs (default false). Classic search only.
`date_posted`	No	Filter by posting date (past_hour, past_24_hours, past_week, past_month)
`experience_level`	No	Filter by experience level, comma-separated (internship, entry, associate, mid_senior, director, executive). Classic search only.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.29.0Nov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnly and openWorld; the description adds substantial behavioral context beyond them — the LinkedIn redesign, which filters are dropped, that drops are surfaced in section_errors as filters_dropped, and that quotes do not force exact phrases. This is exactly the kind of degradation and error-reporting behavior an agent cannot infer from structured fields.

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-loads purpose and the job_id handoff in two short sentences, then a single focused paragraph on the redesign caveat. Slightly wordy in places ('keep doing so'), but every sentence carries actionable 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, yet the description still adds the useful job_ids-to-get_job_details linkage. For a nine-parameter search tool with a nontrivial fallback path, the description covers the failure mode, the workaround, and the error field an agent should inspect.

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 the schema already documents all nine parameters and their values. The description still adds meaning by explaining that several filters are 'Classic search only' and will be dropped on redesigned search, plus keyword syntax caveats (words narrow results, quotes are not exact).

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 verb and resource ('Search for jobs on LinkedIn') and immediately clarifies the output relationship: returns job_ids that feed get_job_details. This distinguishes it from the sibling detail-fetch tool without the agent needing to open either schema.

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?

Gives concrete guidance for the redesigned-search case: when filters are dropped, re-run with location/work type folded into keywords, and notes that words like 'senior' narrow results. It does not discuss when to prefer this over neighboring tools such as search_people, but the domain is clear enough that this is a minor gap.

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