Djinni MCP

Overview Schema Source Related Servers Discussions Admin

search_jobs

Read-only

Search public job listings from Djinni RSS feeds by category, company type, remote-only status, and title keywords to find matching roles.

Instructions

Discover public jobs from RSS. Category is explicit; title_contains is a local literal substring. Limit is 1-50. Offset is inside one feed, not source pagination. Status and country eligibility need get_job. Coverage is unknown; never claim exhaustive results.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_jobs"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`category`	No
`remote_only`	No
`company_type`	No
`title_contains`	No

Output Schema

Name	Required	Default
`jobs`	Yes
`coverage`	No	unknown
`warnings`	Yes
`checked_at`	Yes
`source_url`	Yes
`next_offset`	Yes
`fetched_count`	Yes
`matched_count`	Yes
`returned_count`	Yes
`contract_version`	No	0.1
`possibly_truncated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 9, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses two non-obvious behaviors that would otherwise cause agent errors: offset is scoped inside a single feed rather than over the source, and coverage is unknown so results must never be presented as exhaustive. The 'title_contains is a local literal substring' note also pre-empts a reasonable-but-wrong assumption about server-side fuzzy matching.

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?

Semicolon-delimited facts, front-loaded, with essentially no filler and no repetition of annotation data. The trade-off is over-compression: 'Category is explicit' and 'Limit is 1-50' (the latter already in the schema constraints) spend space less efficiently than the well-formed offset and coverage sentences.

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?

An output schema exists, so return-value explanation is correctly omitted, and the description covers the highest-risk semantics for a 6-parameter open-world search tool. It stops short of saying how filters combine (AND vs. override) and how results are ordered, which an agent doing multi-filter queries would want.

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%, so the description has to carry the load, and it does for the ambiguous parameters: the offset scoping caveat and the literal substring semantics of title_contains add real meaning the schema cannot convey. Gaps remain — remote_only and company_type are never mentioned, and 'Category is explicit' is too compressed to tell an agent whether it means exact match, required-for-good-results, or server-side interpretation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete resource and source ('public jobs from RSS'), which tells an agent this is a discovery/search tool over external feeds rather than the internal job record. It also carves out the boundary with get_job, so sibling confusion is low, though the verb 'discover' is softer than search/list and the 'public' scope is never expanded on.

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 a clear negative routing rule ('Status and country eligibility need get_job'), which is the most valuable when-not-to-use signal for this family. What it lacks is a positive trigger statement (e.g. 'use this to browse listings when you do not yet have a job ID') and any guidance on choosing among the other siblings like save_search or set_job_excluded.

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

Deploy Server