Kollegia – ledige stillinger og lønn i Norge

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: only active jobs are returned, employer page/career page links are included, and ambiguous names yield suggestions rather than an error.

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 compact sentences, front-loaded with the core action and followed by the return/edge-case behavior. No filler or restated name/title content.

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-shape detail is not required, and annotations carry the safety profile. The description covers scope, ambiguity handling and linked output; the only gap is routing guidance relative to sibling tools.

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?

One parameter with 100% schema description coverage, so the schema already documents that employer accepts a name or a kollegia.no slug. The description restates the same name-or-slug duality without adding format, matching, or normalization rules.

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?

States a specific verb and resource: find an employer by name/slug and list its active jobs, plus the returned links. This scopes it clearly against the sibling job tools (get_job, search_jobs), but it never names an alternative tool to make the differentiation explicit.

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 primary use case (look up jobs by employer rather than by keyword) is implied, and the description notes the ambiguous-name fallback. However, it gives no explicit when-to-use vs. when-to-use search_jobs/get_job guidance, leaving routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and idempotency profile is covered. The description adds the domain ('url on kollegia.no') and names the returned fields, but since an output schema exists this return-value detail is largely redundant; no pagination, auth or error behavior is disclosed.

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: verb, resource, id source, and return payload in order of importance. Every clause earns its place.

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 one-parameter read tool with full annotations and an output schema, the definition is nearly complete and the agent has everything needed to invoke it. The one real gap is the unresolved overlap with the get_job sibling, which the description never addresses.

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?

With 100% schema coverage the baseline is 3, and the description goes one step further by telling the agent where the single 'id' value originates (from search or search_jobs), which reduces malformed calls. It does not add format details beyond the schema's 'Job id.'

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?

States a specific verb and resource ('Fetch the full ad for one job by id') plus the payload (title, text, url, key facts as metadata), which is far more than the bare name 'fetch'. However, it never differentiates itself from the near-synonymous sibling get_job, so an agent cannot tell the two apart from the description alone.

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 parenthetical '(from search or search_jobs)' implies the intended search-then-fetch pipeline, which is useful routing context. But there is no explicit when-to-use or when-not guidance, and it does not resolve which of fetch vs. get_job an agent should pick given a job id.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint and closed-world scope, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the ad text is shortened and stripped of contact details, and the call errors when the job is no longer active. Only minor gaps remain (rate limits, caching/freshness).

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?

One front-loaded sentence: the action and subject come first, followed by a compact parenthetical list of returned fields and the error condition. Every clause carries information; nothing is padding.

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 annotations covering safety and an output schema covering return structure, the description only needs to frame scope, id provenance, and failure mode — all of which it does. Nothing an agent needs to invoke this tool correctly 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?

Schema description coverage is 100% and the single id parameter is already documented in the schema with its URL format. The description only restates that the id comes from search_jobs, which the schema effectively conveys, so this is baseline-level added value for a fully-documented parameter.

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?

States a specific verb (Get) and resource (details for one active job on Kollegia) and enumerates the returned fields, so the agent knows exactly what comes back. It also names the sibling search_jobs as the source of the id, cleanly separating this lookup tool from the search tool.

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 the correct workflow by tying the id to search_jobs ("from search_jobs") and warns that an inactive job yields an error, which tells the agent when this call will fail. It stops short of explicitly stating when not to use it versus siblings like employer_jobs or salary_for_occupation, but the context is clear.

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

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

Annotations already declare the safe read-only, idempotent, non-destructive profile, so the bar is lower. The description still adds meaningful behavior: the data provenance (Statistics Norway/SSB for salary, NAV and Kollegia for job counts) and the important caveat that salaries are national while location only affects job counts. It does not discuss caching, latency, or data vintage.

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 dense sentences, front-loaded with the core deliverable, then sources, then the two location caveats. Nothing is filler, though the parenthetical source attributions add length that could be tightened.

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 an output schema present, the description need not enumerate return values, yet it still names the key metrics and their sources, plus the national-vs-local caveat that an agent would otherwise get wrong. For a 2-parameter read-only lookup, nothing needed for correct invocation 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?

Schema coverage is 100%, so the baseline is 3, and the description genuinely exceeds it by explaining the effect of 'location' on the result (adds local open jobs) and stating that it does not change salary figures. That is real semantic value beyond the example lists in 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?

States a specific resource (salary statistics for an occupation in Norway) and enumerates exactly what is produced: median monthly salary, quartiles, estimated hourly wage, plus open-position counts. This is unmistakably distinct from the job-search siblings (search_jobs, get_job, employer_jobs) without needing their schemas.

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 signals when to supply the optional location (to get local open-job counts) and clarifies the boundaries of the salary data ('SSB salaries are national, not per location'), which prevents a caller from expecting location-filtered salary. There is no explicit when-not-to-use or sibling routing, but the tool's domain is narrow and unambiguous.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: query tokens like place names and heltid/deltid/sommerjobb are silently interpreted as filters, and only active listings are searched. It stops short of stating result limits or pagination.

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 tight sentences with zero filler, front-loaded with the core capability and examples before the routing hint. Every sentence earns its place.

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 one-parameter search tool with an output schema, this covers scope, query interpretation, return shape and the follow-up call. Nothing needed to invoke it correctly 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?

Schema coverage is 100%, so the single 'query' parameter is already documented (including Norwegian/English). The description goes beyond that by explaining how the query string is parsed — place names and employment-type words act as filters — which is semantics the schema does not carry.

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?

States a specific verb+resource+scope: free-text search over active job listings in Norway, with concrete query examples ('kokk i Bergen'). It explicitly differentiates itself from the sibling search_jobs, which offers the same thing with explicit filters.

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?

Gives the full workflow: search to get ids, then use fetch with the id for the full ad. It also names the alternative (search_jobs) and the condition that selects it (explicit filters instead of free text), so the agent can route without inference.

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

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

Annotations already cover readOnly/idempotent/destructive/non-openWorld, so the bar is lower, yet the description adds genuinely useful behavior: a 20-result cap, ranking (newest and best title matches first), salary being either ad-stated or an SSB-based estimate flagged "ca.", and Norwegian-only content. It does not, however, explain paging behavior beyond the offset parameter. Note that openWorldHint=false sits slightly awkwardly with the described live external sourcing, though both sources are fixed domains rather than an open web.

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?

Front-loaded with the core verb+resource, then scope and return behavior, closing with the one-line usage rule. Efficient overall, though the long enumerated return-field sentence partially duplicates structured output already exposed by the output schema.

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?

Covers source, geography, language, result cap, ranking, salary-estimate caveat and the at-least-one-filter rule; with an output schema present, the description need not document return shape. An agent has everything required to call it 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?

Schema description coverage is 100%, so the schema already carries parameter meaning and baseline is 3. The description reinforces combination semantics ("combine filters freely", at-least-one rule) but adds no per-parameter syntax beyond what the schema documents.

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?

States a specific verb and resource ("Search active job listings in Norway") and pins the exact data sources (Kollegia, NAV/arbeidsplassen.nav.no). This scope and sourcing distinguish it from get_job (single listing) and employer_jobs (per-employer) without the agent opening either 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?

"Combine filters freely; all are optional but give at least one" gives a real invocation constraint but stops short of stating when to pick this over sibling tools such as get_job or employer_jobs. Usage is implied by the scope rather than explicitly routed.

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