Open base of job vacancies and freelance orders from Russian and international boards and Telegram.
Scored across 3 tools
Each tool occupies a distinct layer: search_leads discovers candidates, get_lead_details expands one lead, and get_market_analytics aggregates statistics across the corpus. The descriptions explicitly state the relationship (search returns compact results, details returns full text/contacts), so misselection is unlikely.
All names are snake_case verb_noun and highly readable: get_lead_details, get_market_analytics, search_leads. The only minor deviation is that search_leads uses a different verb family than the get_* pair, but it is semantically correct and predictable.
Three tools is on the lean side but sits inside the well-scoped 3-15 range for a read-only lead/market radar, and each tool has a clearly non-redundant role. Nothing feels padded or missing at the count level.
The surface covers the core read workflow: search, inspect a single lead, and get aggregate market insight, with pagination and narrowing filters handled via search_leads. Minor gaps remain (e.g. no budget-range filter, no direct lookup by lead id outside a search, no saved-lead/alert state), but an agent can work around these.
Full text, contacts (when the caller may see them), source and budget of one lead.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Lead id from search_leads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral load, and it does disclose one meaningful trait: contacts are returned conditionally based on what the caller is permitted to see. It says nothing about behavior for a missing/invalid lead id, error modes, or whether the response is a single object, leaving real gaps for a read tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the returned fields with no filler. It reads as a noun phrase rather than a sentence, which costs a bit of clarity but wastes nothing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read with no output schema, the description usefully enumerates the returned fields (text, contacts, source, budget) and flags the permission-conditional field. Only error/not-found behavior and permission prerequisites are left uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single id parameter is documented as coming from search_leads, so the description need not repeat it. The description adds no format or constraint details beyond the schema, which is the expected baseline for a fully documented one-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (one lead) and enumerates the returned content — full text, contacts, source, budget — so an agent can tell it apart from the list-oriented search_leads sibling. It lacks an explicit verb, but the retrieval intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus search_leads or get_market_analytics, and no prerequisites are given. The only workflow hint ("Lead id from search_leads") lives in the schema, not the description, so the description itself offers no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top requested skills and the median budget over the latest 200 visible leads.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one meaningful trait: results are computed over only the latest 200 'visible' leads, so the agent knows the sample is bounded and permission-filtered. It omits auth requirements, whether the window is time-based, and what the aggregate response actually contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficient, though so terse that there is no structure beyond the one clause to hang scope or parameter behavior on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an undocumented parameter, the description leaves key gaps: default behavior when `type` is omitted, whether the 200-lead window is fixed or time-bounded, and the shape of the returned analytics. For a schema-less-output tool this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions the single `type` parameter or its job/gig enum. The enum values are fairly self-explanatory, but the description adds no semantics — crucially, it does not say what happens when `type` is omitted (both categories? a default?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the concrete outputs — top requested skills and median budget — over a defined dataset (latest 200 visible leads), which is far more specific than the tool name alone. It implicitly distinguishes itself from get_lead_details and search_leads by being an aggregate view, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement of when to use this versus search_leads or get_lead_details, nor any prerequisites. Usage is only implied by the aggregate nature of the output (market-level stats rather than per-lead data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find job vacancies and freelance orders. Returns the best few in a compact form, newest or best first, with a next_offset to page on; call get_lead_details for the full text and contacts of the ones that fit. Narrow with market, remote, since and skills instead of reading many pages.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | new (default), score = best described first, budget = highest pay first; score and budget look at the last 7 days | |
| type | No | job = employment, gig = freelance order | |
| limit | No | Results per call, 1-50 (default 10) | |
| query | No | Keywords or tech stack, e.g. "Golang Kafka" | |
| since | No | Only posts newer than this: "24h", "7d" or an ISO date | |
| market | No | ru = Russian-language boards and channels, intl = the rest | |
| offset | No | next_offset from the previous call, to read the next page | |
| remote | No | Only work that can be done remotely | |
| skills | No | At least one of these skills, e.g. ["Python", "Django"] | |
| min_budget | No | Minimum budget in the lead's own currency (prefer min_budget_rub) | |
| min_budget_rub | No | Minimum budget or monthly pay, in roubles (other currencies are converted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose that results are partial ('best few in a compact form') and pageable via next_offset, which prevents an agent from assuming it got everything. It doesn't say whether auth is required, whether results are capped server-side, or how paging terminates, so it falls short of full behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool does, then the return shape, then the alternative and filtering advice. Every clause carries information; there is no boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter search tool with no output schema, the description supplies the essential return-shape and pagination context that the schema cannot. It stops short of describing what fields the compact lead record contains (title, budget, skills?), which would fully close the loop for an agent deciding whether to page or drill in.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including enum meanings for sort, type and market, so the schema already does the semantic work. The description only adds a strategic note that market, remote, since and skills are the narrowing levers — useful but not new per-parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource pair ('Find job vacancies and freelance orders') that immediately identifies the domain, then states the return shape ('best few in a compact form'). It also routes a follow-up to get_lead_details, so an agent can distinguish this tool from its sibling 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to call get_lead_details for full text and contacts of matching leads, and advises narrowing with market/remote/since/skills 'instead of reading many pages' — a direct when-to-use and how-not-to-use statement. Nothing about the browse-then-detail workflow is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_lead_detailsget_market_analyticssearch_leadsLive job vacancies and salary stats: Russia, Belarus, Kazakhstan, Germany, France and more.
Hire freelancers or find work on a no-commission board in 6 languages, for people and AI agents: search offers and requests, message authors (auto-translated), propose terms. Read-only search needs no account; full access signs in with Telegram or email via OAuth 2.1, and sensitive steps wait for the person's approval.
Telegram/VK audience scraping, marketplaces, Russian government registers. Free open dataset.
Search ~1.4M open jobs from 24k company career boards: Greenhouse, Lever, Ashby, Workday and more
Add one secure layer between your agents and this server.
