Skip to main content
Glama
Sign In
jobvision-mcp

jobvision-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Search jobs

jv_search
Read-onlyIdempotent

Search Jobvision job ads by keyword, location, category, salary, and other filters to find matching roles and return one page of compact job cards.

Instructions

Search Jobvision job ads (استخدام) with filters and return one page of compact job cards.

Use this first for any job hunt. Each job has an id: call jv_job for its full text, jv_company for the employer and its other ads, jv_similar_jobs for related ads. applied echoes the filters Jobvision recognised. Pay is the advertised monthly range in million Toman; most ads hide it. Use jv_pay_stats for pay levels of a role.

Input Schema

NameRequiredDescriptionDefault
cityNoCity, province or Tehran area, by name (اصفهان, Isfahan) or slug (isfahan, all-cities-of-tehran, tehran-shomal). One place only. See jv_locations.
pageNoPage number, 1-based.
sortNonewest (default), relevance (best title match) or salary (highest top of the advertised range first).newest
limitNoAds per page.
remoteNoOnly remote jobs.
benefitNoBenefit id from jv_options('benefits'), e.g. 116 = loan.
keywordNoJob title or skill, Persian or English, e.g. python, حسابدار, برنامه نویس.
categoryNoJob category slug or name from jv_options('categories'), e.g. developer, sales, accounting.
industryNoIndustry id from jv_options('industries').
seniorityNoLevel of the role: intern, worker, employee, specialist (کارشناس), senior-specialist, manager (middle), senior-manager, ceo.
work_typeNofull-time, part-time or project-based (contract).
experienceNoRequired years of experience bracket; none means 'no experience needed'.
governmentNoOnly government and public-sector ads: all, or one sector (banks, education, ministries, insurance, industry, health, oil-gas, armed-forces, other).
internshipNoOnly internships.
salary_minNoOnly ads whose advertised pay reaches at least this many million Toman per month. Ads that hide the pay are left out.
posted_withinNoOnly ads posted in the last 3 days, week, 15 days or month.
military_serviceNoOnly ads offering military-service benefits (امریه).
disabled_friendlyNoOnly ads marked suitable for people with disabilities.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent and open-world, so the bar is lower. Beyond them the description discloses that results are paginated to one page of compact cards, that 'applied' echoes only the filters Jobvision recognised (a real silent-drop warning), and that most ads hide pay. It does not mention rate limits or what a card contains, but the added context is substantive.

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?

Purpose and the 'use this first' directive are front-loaded, and the follow-up routing is compressed into one sentence. A few clauses (pay explanation) sit slightly awkwardly after the routing, but there is no filler.

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?

For an 18-parameter, all-optional search with no output schema, the description covers the essentials: what comes back, pagination, filter-echo behaviour, and the sibling chain for depth. It would be stronger if it sketched the fields of a compact job card, since there is no output schema to do that.

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?

Schema coverage is 100%, so every parameter is already documented with examples and enums. The description adds only the pay unit (million Toman per month) and the prevalence of hidden pay, which is useful interpretation but not new parameter syntax. Baseline 3 is appropriate.

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 Jobvision job ads') plus the return shape ('one page of compact job cards'). That return-shape clause also separates it from jv_job, jv_company and jv_similar_jobs, which are named as follow-ups.

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?

'Use this first for any job hunt' gives an explicit entry point, and the id-then-follow-up chain (jv_job for full text, jv_company for employer, jv_similar_jobs for related) tells the agent what to do after a hit. No explicit when-not-to-use case is stated, so it stops short of a 5.

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

Deploy Server

Other Tools