Skip to main content
Glama
umilutinovic25-hash

poslovi-mcp

by umilutinovic25-hash
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

poslovi-mcp

MCP server + CLI for searching Serbian job boards — poslovi.infostud.com and helloworld.rs — from Claude (or any MCP client) or straight from your terminal.

No API keys, no accounts: it reads the public listing pages and the schema.org JobPosting JSON-LD that both boards embed on every posting.

$ poslovi search "ai engineer"
  1. AI Automation & Lead Operations Specialist   Thrive Talent Solutions  [infostud]
     https://poslovi.infostud.com/posao/ai-automation-lead-operations-specialist/...
  2. Senior Data Engineer (Technical Leadership)  Keba d.o.o.  [helloworld]
     https://www.helloworld.rs/posao/Senior-Data-Engineer-Technical-Leadership-Track/...

Install

python3 -m venv .venv && source .venv/bin/activate
pip install -e .            # or: pip install -e ".[dev]" for tests

Related MCP server: MCP Job Toolkit

CLI

poslovi search "python developer"              # both boards
poslovi search "ml engineer" --board infostud  # one board
poslovi search "devops" --page 2               # pagination
poslovi show <posting-url>                     # full posting text + deadline

MCP server

The same functionality as two MCP tools, search_jobs and get_job, served over stdio:

# Claude Code
claude mcp add poslovi -- /path/to/poslovi-mcp/.venv/bin/poslovi-mcp

or in any MCP client config:

{
  "mcpServers": {
    "poslovi": {
      "command": "/path/to/poslovi-mcp/.venv/bin/poslovi-mcp"
    }
  }
}

Then just ask: "nađi mi AI poslove u Beogradu i izdvoji one sa LLM iskustvom" — the model searches, opens the interesting ones, and reasons over the full posting text.

How it works

  • boards.py — one parser for both boards (they share a platform): listing pages are matched by the /posao/{slug}/{company}/{id} URL pattern, detail pages by their JobPosting JSON-LD block, with page text as fallback.

  • server.py — FastMCP server exposing search_jobs / get_job.

  • cli.py — standalone CLI, no MCP client needed.

  • tests/ — offline parser tests against recorded HTML fixtures.

Tests

pytest

Available Tools

2 tools
get_jobA

Fetch one job posting and return its full details.

Args: url: Posting URL returned by search_jobs.

Returns: JSON object with title, company, location, dates, employment type, qualifications, and the posting text.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, but the description indicates a read-only fetch operation and lists the return fields. This adequately communicates the tool's behavior for a simple retrieval endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-organized with Args and Returns sections. Every sentence adds value, and no repetition exists.

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?

The tool is simple with one parameter. The description explains the parameter, output structure, and relationship to the sibling. Given the presence of an output schema (not shown), this is complete.

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 description coverage is 0%, but the description adds meaning: 'Posting URL returned by search_jobs', which clarifies the parameter's origin and expected format beyond the schema's type-only definition.

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 explicitly states 'Fetch one job posting and return its full details', using a specific verb and resource. The sibling tool 'search_jobs' implies a listing function, so this tool is clearly distinct.

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?

The description notes that the URL comes from 'search_jobs', establishing a clear sequence. However, it does not explicitly state when not to use this tool or provide alternatives beyond the sibling.

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

search_jobsA

Search job postings on Serbian job boards.

Args: query: Search terms, e.g. "python developer" or "AI engineer". board: "infostud", "helloworld", or "all" (default) for both. page: Results page, starting at 1.

Returns: JSON list of postings with title, company, url, board, and id.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
boardNoall
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

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

Describes return format as JSON list with fields but does not disclose auth, rate limits, or side effects. No annotations to rely on.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise docstring with Args and Returns sections, no wasted words, purpose stated upfront.

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?

Covers parameters and return structure sufficiently for a search tool; could specify pagination limits but adequate.

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?

Input schema has 0% description coverage; the description adds examples for query, board choices, and page default, compensating well.

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 clearly states 'Search job postings on Serbian job boards.' with a specific verb and resource, and distinguishes from sibling 'get_job'.

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?

Provides guidance on query, board options, and page. Does not explicitly contrast with 'get_job', but context implies search vs single retrieval.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedget_job
    • First observedsearch_jobs
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: search_jobs lists job postings matching a query, while get_job retrieves full details for a specific posting. No overlap or ambiguity exists.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (search_jobs, get_job), making the naming predictable and easy to understand.

Tool Count4/5

With only 2 tools, the set is minimal but appropriate for a focused read-only job board API. It slightly undershoots the typical 3-15 range but still feels well-scoped.

Completeness4/5

The tools cover the core read operations (search and detail retrieval) for job postings. Missing features like filtering by location or job type are minor gaps that don't severely impact usability.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Job Toolkit

    afrozk
    F
    license
    A
    quality
    D
    maintenance
    An MCP server that enables searching for jobs across Australian platforms (Seek and LinkedIn) from Claude or any MCP-compatible client, with filters for location, salary, employment type, and more.
    1
    4
    -

  • JobSpy MCP Server

    chinpeerapat
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables job search and scraping across multiple job boards (LinkedIn, Indeed, Glassdoor, etc.) with advanced filtering, directly from Claude Desktop or other MCP clients.
    6
    MIT

  • Whoishiring MCP Server

    nickw409
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables Claude Desktop to scan, analyze, and track job postings from Hacker News and Y Combinator's Work at a Startup using a 24-tool MCP server with multi-stage filtering and resume-based ranking.
    -