Instead

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description's job is to add context — and it does, by enumerating the returned fields and qualifying that only a 'live' job is returned. It stops short of saying what happens when a job is expired or the slug is invalid, which is the main remaining gap.

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 listing the payload contents with no filler. It is slightly informal ('what it involves', 'what's needed') where precise field names would be stronger, but nothing is wasteful.

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 schema coverage and clear annotations, this is close to sufficient: the agent knows what it gets back and that it is a safe read. Only the missing linkage to search_jobs and the not-found/expired behavior keep it from being complete.

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% and the parameter already documents 'The job's link or slug from search_jobs', including length bounds. The description adds nothing about the identifier format, so the baseline 3 is correct — the schema does all the work here.

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 makes clear this retrieves the full detail record for a single job, enumerating what that record contains (pay, hours, requirements, business, apply link). The 'one live job' phrasing implicitly separates it from the plural search_jobs sibling, though it never names the sibling 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 statement of when to call this versus search_jobs, nor any prerequisite such as 'call search_jobs first to obtain the job link or slug'. The workflow hint exists only in the schema's parameter text, not in the description, so the agent must infer the lookup sequence.

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=true and destructiveHint=false, so safety is covered. The description adds genuine value by enumerating the advice topics (sourcing via people who know the business, pay, UK rules, Instead costs), but says nothing about how the response is shaped or whether the advice is personalized.

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 sentence, front-loaded with the target user and then the content areas. No filler, though the parenthetical sector list is slightly longer than needed for disambiguation.

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 read-only advice tool with two optional params and no output schema, the definition covers what topics come back but not how area/role influence the answer or what form the guidance takes. Adequate, but an agent has to guess at the effect of its inputs.

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 both optional parameters (area, role) are already documented with examples in the schema. The description neither names nor explains them, and does not indicate whether supplying area or role tailors the guidance — baseline 3 applies.

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 frames the resource: hiring guidance for small UK business owners, scoped to specific sectors (café, pub, restaurant, bar, shop, salon) and four content areas. It does not differentiate itself from siblings, notably pay_rates, which overlaps with its 'what to pay' coverage, and post_job/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 audience condition ('a small UK business owner who needs staff') implies when to call, but there are no exclusions or named alternatives — an agent cannot tell whether to use this or pay_rates for a pay question, or this vs. make_hiring_poster before posting.

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 read-only, non-destructive, closed-world behavior. The description adds useful output detail (three poster sizes, QR code), but does not state the return format (files, links, images) or whether generation is immediate, which are important behavioral traits for a generator tool.

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 tightly written sentences with zero waste. The output description is front-loaded, followed immediately by the accepted input sources.

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?

The description is largely complete for a tool whose annotations cover safety and whose schema fully documents parameters. It clearly describes what posters are produced and what inputs are accepted, though without an output schema it could say more about the return format.

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 all five parameters are already documented in the schema. The description reinforces the accepted forms of the 'job' parameter and mentions its source (post_job or live job), but adds little about the other four parameters beyond what the schema provides.

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 (making print-ready hiring posters) and enumerates the concrete outputs: A4 window poster, A5 poster, and A6 table card with QR codes. This is clearly distinguishable from sibling tools like post_job 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?

Explains when the tool applies: for a job created with post_job (by code or link) or a live Instead job (link or slug). It gives clear usage context but does not explicitly name alternatives or exclusions, leaving some inference to the agent.

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/non-destructive/closed-world, so the description's added value is provenance and recency: independent venues only (chains excluded), self-advertised pay rather than survey data, and a one-month window. That is exactly the kind of context annotations cannot convey. It stops short of caveats about sample size or what happens when only a handful of ads exist for a role.

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 sentences, front-loaded with the substance and with no filler. The venue enumeration is slightly long but does real work by defining the population boundary; the parenthetical index citation is mild decoration.

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?

There is no output schema, so the description carries the burden of describing returns — and it does, naming median, range and ad volume. Combined with one optional parameter and full annotation coverage, the only gap is edge-case behavior for an unrecognized or sparse role.

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 a single parameter at 100% schema coverage, the schema already documents `role` as free-text with examples (barista, chef, kitchen porter) and the omit-for-all-roles default. The description only restates "by role" and adds no matching guidance, such as how to phrase a role that may not be indexed.

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 exactly what data comes back (median, range, ad count) for a precisely bounded population: hourly pay advertised by independent London cafés, restaurants, pubs, bars and bakeries on their own websites, this month. That scope definition cleanly separates it from the sibling job-listing tools (search_jobs, post_job, get_job), which deal with individual postings rather than aggregate market pay.

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?

"For an owner choosing what to pay, or someone weighing up a job" gives an implied audience and therefore an implied when-to-use, but there is no explicit routing: no when-not-to-use, no mention of alternatives, and no statement that this cannot answer questions about a specific vacancy (which is what the sibling tools are for).

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=false, openWorldHint=true and non-idempotent, so the mutation profile is covered. The description adds genuinely non-obvious behavior: the post is public and accepting applications immediately upon creation, the owner only sees/answers applicants after opening the publish link and signing in (~30 seconds), and applications arrive via link and QR code. It does not warn about duplicate postings, given idempotentHint=false.

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?

Wait—reconsidering: the description is three long sentences with a slightly tangled middle clause about the publish link and sign-in, but each sentence carries distinct information (what it makes, how applications flow, what is public). It is front-loaded with the purpose and contains no 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 13-parameter creation tool with no output schema, the description covers the workflow but never states what the caller gets back (presumably the job link and QR code) or how to read/answer applicants afterwards via get_job. Optional parameters such as city, country, pay_unit, temporary and description are left entirely to the schema.

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 77%, so the schema already documents most fields with examples (area, role, pay, hours, must_haves). The description echoes the headline fields (business name, pay, hours, area) and notes the business name is what appears publicly, but adds no syntax or format detail 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?

The first sentence gives a concrete verb and resource ("Make a job for a small business on Instead") and states it is free, so an agent knows this is the create-side counterpart to get_job/search_jobs. It never names those siblings explicitly, so differentiation is inferred from the read/write split rather than stated.

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?

Usage is only implied: the description makes clear this is the tool that publishes a new opening, and it hints at a prerequisite by saying the owner must sign in with their email to publish. It gives no explicit when-to-use versus how_to_hire, make_hiring_poster, or pay_rates, and no when-not-to-use conditions.

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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful behavior beyond that: results are a mix of Instead-hosted and external independent listings, every job shows pay, and external applications go through the employer's site or a shared leave_details_url. It stops short of disclosing result limits, ordering rules, 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?

The two-sentence block is a single promotional run-on, front-loaded with the resource (good) but padded with applicant-experience copy ('applying takes about two minutes from a phone with no account... within 48 hours') that does not help an agent select or call the tool. The operational content — the external-listing branch and leave_details_url — is buried at the end.

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?

There is no output schema, so the description carries the burden of explaining what comes back, and it does the most important part: results are heterogeneous (Instead listings vs. places hiring on their own sites vs. new UK places), with different follow-up actions for each. Missing result-count/pagination behavior keeps it from a 5, but it is sufficient to call 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% and all three filters (area, query, min_hourly_pay) are documented with examples in the schema, so the baseline is 3. The description adds no filtering or syntax detail of its own — notably it never mentions that the search can be narrowed by area, keyword, or pay, which is the tool's main invocation lever.

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 opening clause names the resource and scope precisely ('Live jobs at independent UK cafés, pubs, restaurants, bars, shops and salons on Instead, London first'), which is more specific than the sibling names alone would allow. It does not use a clean verb-first phrasing, and the marketing tail dilutes the signal, but an agent can still distinguish it from get_job and post_job.

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 (browse/search listings, then apply on-site or at leave_details_url) but never states when to pick this over get_job or pay_rates. There are no explicit exclusions or preconditions (e.g. 'use get_job once you have an id'), so routing must be inferred from the tool name.

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