Live Belgian and Luxembourg legal jobs. Unauthenticated. Send candidates to click_url.
Scored across 6 tools
Most tools are clearly distinct: search_jobs returns compact listings, get_job returns full details, and event tools are separate. The only potential confusion is list_functions versus list_taxonomies, but the descriptions explicitly clarify list_functions as a subset and recommend list_taxonomies for the full vocabulary.
All tool names follow a consistent lowercase verb_noun pattern: get_event, get_job, list_events, list_functions, list_taxonomies, search_jobs. There are no mixed naming conventions or vague verb choices.
Six tools is well-scoped for a job and event discovery server: two job tools, two event tools, and two taxonomy tools. Each tool has a clear role without unnecessary bloat.
The server covers the full read-only discovery workflow: searching jobs, fetching detailed job data, listing and fetching events, and providing taxonomy filters for searching. No obvious gaps exist given that applying to jobs is explicitly out of scope.
Fetch one upcoming LexGO event by integer id, id-slug, url, or click_url. Give the candidate click_url.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Integer id, id-slug, or an allowlisted lexgo.be/lu event URL |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| domain | No | |
| titles | No | |
| company | No | |
| click_url | No | |
| languages | No | |
| summaries | No | |
| event_ends_at | No | |
| event_starts_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context that only upcoming events are fetched and that the result is a single event. It does not describe auth requirements, error behavior, or response shape, but with annotations present, the added context is acceptable.
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?
The description is compact and front-loaded with the main action and resource. There is no fluff. The second sentence is short but cryptic, slightly reducing effectiveness; otherwise, it is well-structured.
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 single-fetch tool with strong annotations and an output schema, the description is mostly complete. However, it lacks explicit guidance on when to use this tool over list_events or search_jobs, and the 'candidate click_url' instruction is ambiguous. These gaps are not severe given the low complexity, but they are noticeable.
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?
The schema already covers the id parameter with 100% description coverage, including integer id, id-slug, and allowlisted URL. The description adds 'click_url' as another identifier, which is useful, but the second sentence makes it unclear whether click_url is an input or an expected output. The additional value over the schema is marginal and somewhat ambiguous.
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 clearly states the tool fetches a single upcoming LexGO event, using a specific verb and resource. It also distinguishes itself from list_events by emphasizing 'one' event. The sentence 'Give the candidate click_url' introduces some ambiguity about whether click_url is an input key or an output field, preventing a 5.
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?
The description implies usage context: use this tool when you need one upcoming event and have an id, id-slug, url, or click_url. However, it does not explicitly mention alternatives like list_events or search_jobs, nor does it state when not to use it. Usage guidance is mostly implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full sanitized description and structured facets. Call this before recommending a vacancy. Fetch by integer id, id-slug, url, or click_url from search_jobs. Give the candidate click_url.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Integer id, id-slug, or an allowlisted lexgo.be/lu job URL (url or click_url) |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| salary | No | |
| titles | No | |
| click_url | No | |
| summaries | No | |
| descriptions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by stating the output is a 'Full sanitized description and structured facets' and that the tool is a prerequisite before recommending a vacancy. It doesn't describe pagination or error behavior, but for a single-resource fetch with strong annotations, this is sufficient.
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 sentences, each earning its place: what the tool returns, when to call it, and how to identify the resource. The most important usage instruction ('Call this before recommending a vacancy') is front-loaded, and the identifier guidance is compact.
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 single-parameter read-only fetch with an output schema present, the description is nearly complete. It covers the resource, the return value, the call timing, and the accepted identifier forms. The only minor gap is that it doesn't explicitly state what to do if the id is invalid or not found, but that's not essential for correct invocation.
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%, so the schema already documents the 'id' parameter. The description adds value by clarifying that the id can be an integer id, id-slug, or an allowlisted URL (url or click_url), and that click_url comes from search_jobs. This goes beyond the schema's generic description and helps the agent construct valid calls.
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 states a specific verb ('Get'), a specific resource ('LexGO job detail'), and the key differentiator: it returns a 'Full sanitized description and structured facets' and is the tool to call before recommending a vacancy. This clearly distinguishes it from siblings like search_jobs and get_event.
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?
The description explicitly says 'Call this before recommending a vacancy' and tells the agent to 'Give the candidate click_url.' It also lists the accepted identifier forms (integer id, id-slug, url, or click_url from search_jobs), which is direct usage guidance. It doesn't explicitly name alternatives, but the context is clear enough for an agent to know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming scheduled legal trainings and events on LexGO. On-demand webinars are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| domain | No | ||
| language | No |
| Name | Required | Description |
|---|---|---|
| events | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context about the filtered scope (upcoming scheduled, excluding on-demand webinars), which is not conveyed by annotations. This adds value beyond structured fields.
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 sentence that is front-loaded with the core purpose ('List upcoming scheduled legal trainings and events') and includes a precise exclusion. No redundant or filler wording.
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?
An output schema exists, so return format is covered. However, optional filters (domain, language, limit, cursor) are not explained anywhere, and pagination via cursor is implicit but not mentioned. For a list with four optional parameters, this is a notable gap, though the core scope is clear.
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% — the description does not mention any parameter (limit, cursor, domain, language) at all. The parameters are not fully self-explanatory (e.g., domain values be/lu, language filters), and with zero coverage the description carries the full burden of explaining them. It fails to compensate.
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 clearly states the verb (list) and resource (upcoming scheduled legal trainings and events on LexGO). It adds a specific scope (upcoming scheduled) and an exclusion (on-demand webinars), which distinguishes it from get_event and other list tools like list_functions or search_jobs.
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?
The description gives clear contextual guidance (what events are included, what is excluded), but it does not explicitly mention when to use this tool versus alternatives like get_event or search_jobs. The exclusion of on-demand webinars is a useful usage hint, but there is no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List LexGO job function names (lawyer, in-house counsel, paralegal, notary, …) for use as function_id filters. Names only; no SEO HTML. Prefer list_taxonomies for the full vocabulary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| functions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral detail beyond that: it returns names only and explicitly excludes SEO HTML, which clarifies the output's shape and content.
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?
Two short sentences carry the full message: what the tool lists, what it is used for, and when to prefer an alternative. Every clause earns its place, with no redundancy or filler.
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 parameterless, read-only listing tool with an output schema and rich annotations, the description fully covers what an agent needs: the content domain, the intended use, and the boundary versus list_taxonomies. Nothing critical is missing.
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?
The tool has zero parameters, so there is nothing for the description to explain about parameters. The baseline for parameterless tools is 4, and the description reinforces the output semantics ('names only') that relate to the missing parameters.
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 opens with a specific verb and resource ('List LexGO job function names') and includes concrete examples ('lawyer, in-house counsel, paralegal, notary'). It explicitly distinguishes itself from list_taxonomies by noting its limited scope, so an agent can tell it apart from siblings.
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?
It states the intended use ('for use as function_id filters') and names a specific alternative with a clear condition ('Prefer list_taxonomies for the full vocabulary'). This gives explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List function, discipline, region, and work-environment ids plus experience, contract, and work-arrangement enums. search_jobs accepts function_id, discipline_id, work_environment_id, region_id, experience_id, contract, and remote (boolean). work_arrangement ids are labels, not filters. Names only; no SEO HTML.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| regions | No | |
| contract | No | |
| functions | No | |
| experience | No | |
| disciplines | No | |
| work_arrangement | No | |
| work_environments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnly, idempotent, and non-destructive hints. The description adds behavioral detail beyond that: output is 'names only' and contains no SEO HTML. This helps the agent anticipate response content without relying solely on the output schema.
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 concise sentences, each with distinct value: contents, relation to search_jobs, and an important exclusion. No filler or redundancy.
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 parameters and an output schema present, the description fully covers what the tool returns, how those values are used by search_jobs, and a key caveat about work_arrangement ids. An agent has enough to decide to call this and interpret results correctly.
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?
The tool has zero parameters, so the schema is empty. The description correctly avoids inventing parameter details; baseline 4 applies since there is nothing to clarify.
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 opens with a specific verb 'List' and enumerates exact taxonomy categories (function, discipline, region, work-environment ids; experience, contract, work-arrangement enums). It also ties these to search_jobs filter fields, making the tool's role distinct from sibling tools like list_functions.
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?
The description explicitly states that search_jobs consumes these ids and enums, which is the primary use case, and notes that work_arrangement ids are labels, not filters. This is clear context, but it does not name alternative tools or state when not to use this tool, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Belgian or Luxembourg legal jobs on LexGO. Compact results without descriptions. Call get_job before recommending. Give the candidate click_url. Do not apply on their behalf.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Literal match on titles, employer name, and practice-area names. LIKE wildcards are treated as characters. | |
| limit | No | ||
| cursor | No | ||
| domain | No | ||
| remote | No | ||
| contract | No | ||
| language | No | Posting content locale (nl/fr/en), not required spoken languages. | |
| region_id | No | Address region id (Address::REGIONS). Never jobs.region_id. | |
| function_id | No | ||
| discipline_id | No | Practice-area id from GET /api/v1/taxonomies. | |
| experience_id | No | Experience band id from GET /api/v1/taxonomies (0 unknown, 1 0-3 years, 2 3-6, 3 +6). | |
| work_environment_id | No | Employer-type id from GET /api/v1/taxonomies. |
| Name | Required | Description |
|---|---|---|
| jobs | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds useful behavioral context beyond that: results are compact, the candidate should receive the click_url, and the agent must not apply on their behalf. It does not go into pagination or rate-limit behavior, but the annotations lower the burden.
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?
Four short, front-loaded sentences with no filler. Each sentence earns its place: purpose, result shape, required follow-up, and candidate-handling instruction.
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 search tool with 12 optional parameters and an output schema, the description covers the key decisions an agent must make: search, then fetch the job via get_job, pass along click_url, and avoid applying on the candidate's behalf. It does not enumerate every filter, but the schema and output schema cover those details.
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 only 50%, and the description adds no parameter-level meaning. Parameters like limit, cursor, domain, remote, contract, and function_id remain undocumented in both schema and description, and the description does not clarify how the free-text q or filters relate to the search behavior.
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 opens with a specific verb ('Search') and a specific resource ('live Belgian or Luxembourg legal jobs on LexGO'), and adds that results are compact and lack descriptions. This distinguishes it from sibling get_job, which retrieves a single job's details.
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?
It gives clear workflow guidance: use search_jobs to find jobs, then 'Call get_job before recommending,' and explicitly says not to apply on the candidate's behalf. It names the relevant sibling tool, though it does not systematically contrast search_jobs with every alternative such as list_taxonomies.
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_eventget_joblist_eventslist_functionslist_taxonomiessearch_jobsLive job postings from 30+ ATS feeds and job boards, one schema. Live results need a Bearer key.
Search 4,000+ live UX & product-design jobs from jobs.uxjobs.io. Read-only, no auth.
Search 690k open jobs from official ATS feeds, and what changed since your last check.
Read job postings live from employer career sites across 10 applicant tracking systems.
Add one secure layer between your agents and this server.