Skip to main content
Glama
jobvision-mcp
by sepehr071

Filter options

jv_options
Read-onlyIdempotent

Retrieve valid Jobvision filter values—IDs, slugs, and Persian/English names—for categories, industries, benefits, and other search options to build accurate jv_search queries.

Instructions

List the values of one Jobvision filter: ids and slugs with Persian and English names.

Use categories for jv_search's category slug, industries for industry, benefits for benefit (ids). The other lists document what the fixed choices of jv_search mean (jv_search takes friendly names for those).

Input Schema

NameRequiredDescriptionDefault
kindYesWhich list: categories (job categories, 77), industries, benefits, work_types, seniority, experience, salary_ranges, posted_within.

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 declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds value beyond them by disclosing the shape of the returned values (ids, slugs, Persian and English names), which the annotations cannot express and which tells the agent what it can do with the result.

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?

Three short sentences with the primary purpose front-loaded and no filler. The final parenthetical about jv_search taking friendly names is slightly elliptical, but the description still reads quickly.

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 a one-enum lookup tool with full annotation coverage and no output schema, the definition covers purpose, value-to-consumer mapping, and return shape. The only gap is that it doesn't say whether the lists are exhaustive or whether the fixed-choice lists (work_types, seniority, etc.) should be read directly or simply trusted.

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% and the single `kind` enum is fully enumerated with short glosses, so the baseline of 3 applies. The description does add the mapping from `category`/`industry`/`benefit` values to their use in jv_search, but it adds no detail for work_types, seniority, experience, salary_ranges, or posted_within beyond the 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?

The description opens with a specific verb and resource — 'List the values of one Jobvision filter' — and states what comes back: ids and slugs with Persian and English names. That is a distinct job from every sibling (jv_search, jv_locations, jv_suggest), so an agent can route here without opening the 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?

It gives concrete when-to-choose guidance by tying each enum value to its consumer: 'categories for jv_search's category slug, industries for `industry`, benefits for `benefit` (ids)'. It stops short of saying the tool should be called before jv_search to resolve friendly names to ids, and the closing sentence about 'the other lists' is loose about which values those are.

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