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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the danger profile is covered. The description adds one genuinely useful side effect — the linked email alert stops with the search — but says nothing about reversibility, error behavior for an unknown ID, or whether other users' data is affected. The second sentence largely restates the first rather than adding new behavior.

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?

It is short and front-loads the verb, but the two sentences are near-duplicates: 'and its email alert' versus 'its email alert stops with it.' The repetition occupies the space where a warning about irreversibility would have been more valuable.

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 destructive delete with full schema coverage, rich annotations and no output schema, the description is close to sufficient. The remaining gap is the absence of any explicit irreversibility or failure-mode statement, which matters more here than for a read tool.

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 single parameter already documents itself as 'saved_search_id from list_saved_searches.' The description adds no format, sourcing, or constraint detail beyond the schema, so the baseline of 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?

States a specific verb (Delete) and resource (one of this account's saved project searches), scoped to the signed-in account. It is clearly distinguishable from save_search and list_saved_searches by the destructive verb, though it does not name the sibling it complements.

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 when-to-use or when-not-to-use guidance, no mention that the ID should come from list_saved_searches (that hint lives only in the schema), and no prerequisite or confirmation guidance for a destructive action.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful scope by listing sensitive returned data such as email, buyer stats, unread messages, and favourites, but does not disclose additional behavioral traits like authentication requirements or rate limits.

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 front-loaded with a high-level summary followed by a detailed field enumeration. It is appropriately sized, though there is some duplication between the first sentence's mention of buyer stats/unread messages/favourite counts and the second sentence's elaboration of those fields.

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 return values, and it does so thoroughly by enumerating member id, name, email, account type, location, currency, profile URL, unread messages, buyer stats, and favourite/watch counts. With zero parameters and full annotation coverage, the definition is complete enough 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?

This tool takes zero parameters, so there are no parameter semantics to clarify. The baseline score of 4 applies because the schema has no parameters and the description does not need to compensate for missing parameter documentation.

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 uses a specific verb-resource pairing ('The signed-in PeoplePerHour account') and enumerates the returned fields, so the agent knows exactly what data this tool fetches. It also distinguishes itself from sibling tools like get_freelancer by emphasizing that it returns the account the tools act as, i.e., the current signed-in identity rather than another user.

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 provides clear context for when to use it: retrieving the signed-in account and the identity behind all tool actions. It does not explicitly name alternatives or when-not conditions, but for a zero-parameter self-account read, the practical ambiguity with siblings is low.

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 read-only, idempotent, and open-world safety, and the description adds real behavioral context on top: reviews cannot be paged so only recent_reviews carry text, the reviews field is a total count, portfolio is capped at 30 items, and all times are UTC. These are constraints an agent could not infer from 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?

The opening one-line summary is front-loaded and the detail flows from it, with every clause covering a distinct aspect of the return value. It is slightly redundant, since the lead line and the 'Returns a freelancer's public profile' sentence restate the same scope before getting to specifics.

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 output schema, the description carries the full burden of describing return values, and it does so field-group by field-group including the review-pagination caveat. An agent knows what to expect back and how to interpret the reviews versus recent_reviews distinction.

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 sole parameter's description already explains the accepted ID sources, so the description only restates that same information. A baseline 3 is appropriate since the schema does the heavy lifting and the description adds no new format or syntax detail.

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 and enumerates exactly what comes back: rate, CERT level, rating, skills, About text, portfolio items, and reviews. It is clearly the single-profile counterpart to search_freelancers, so an agent can distinguish it from all listed siblings without opening a 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?

Tells the agent where the required identifier comes from (search_freelancers, an Offer, or a profile URL), which is the practical gating condition for calling it. It does not explicitly say when not to use it or name a competing tool for a given scenario, so it falls short of full routing guidance.

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?

With readOnlyHint, idempotentHint and openWorldHint already declared, the description adds value by disclosing the return shape in detail: prices in both account and seller currencies, star-count rating breakdown, add-ons with extra days, and image links. It does not mention auth requirements or failure behavior when an offer_id is stale or 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?

The opening sentence is front-loaded and the input instruction sits at the end where an agent looks last for the action step. The return-field enumeration is long and partially restates the opening line, costing a little density but earning its place since there is no 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?

No output schema exists, so the description carries the burden of explaining the return payload, and it does so thoroughly across currency, delivery, rating distribution, add-ons and seller identity. For a one-parameter read tool with full annotation coverage, nothing essential 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 parameter is already documented in the schema as 'offer_id from search_offers, or the Offer's page URL.' The description repeats that guidance nearly verbatim, adding no new syntax or format detail, so the 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 names a specific verb and resource ('One Offer with its full description...') and immediately scopes it as a single-record fetch, which cleanly separates it from the sibling search_offers. The enumeration of what 'one Offer' contains makes the object concrete rather than abstract.

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?

'Pass an offer_id from search_offers or the Offer's URL' establishes the retrieval workflow and the valid input provenance. It does not state explicit when-not conditions, but for a single-record getter the alternative (search_offers) is obvious from the naming and the description reinforces it.

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, so the description's job is context, and it delivers: 'as its public page shows it' sets the visibility scope, 'Times are UTC' removes timestamp ambiguity, and 'whether it is still open' flags a status field. It does not say what happens for a deleted or private project_id, which is the 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?

The lead sentence front-loads the payload well, but the second sentence re-enumerates the same fields (budget, buyer, proposals) at greater length, so a meaningful share of the text is repetition rather than new information.

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 output schema, the description carries the return-value burden and does so by listing the returned fields and the UTC time convention. For a one-parameter read tool that is nearly sufficient; only edge-case behavior (missing/closed project) is unaddressed.

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?

Single parameter with 100% schema description coverage, so the schema already defines project_id and its two accepted forms. The description restates the same guidance ('from search_projects or the project's URL') without adding format rules or validation behavior, so 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?

Names a specific verb and resource ('One project's full brief') and enumerates exactly what comes back: budget, attachments, interview questions, buyer, proposal count. The reference to pulling the id from search_projects makes the single-record scope unambiguous against that sibling and list_my_projects.

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?

'Pass a project_id from search_projects or the project's URL' tells the agent both where the identifier comes from and the preceding step in the workflow. It stops short of explicit exclusions (e.g., use list_my_projects for bulk, or what to do when a project is closed), so not a full 5.

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, open-world, so the safety profile is covered. The description adds real substance beyond that: a bounded result set of 10 categories, budgets broken out by fixed price vs hourly and by the four freelancer levels, and per-currency values — information that matters because no output schema exists. It stops short of noting any rate limits or whether budgets are cached/updated, which keeps it off a 5.

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-line summary sentence up front, followed by a compact expansion that stays on the resource itself. There is no filler, no repeated title restatement, and the most important identity/cardinality fact is front-loaded.

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 output schema, the description carries the burden of explaining return values, and it does: categories, subcategories, and median budgets by pricing model, freelancer level, and currency. Combined with a single optional, fully documented enum parameter and read-only annotations, an agent has everything needed 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 coverage is 100%, so the baseline would be 3, but the description earns above baseline by clarifying that the currency applies to the median budgets and that values are supplied 'in the currency asked for' — reinforcing the enum's meaning and reminding the agent the default is GBP via the schema. It adds interpretation rather than merely restating the property.

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 resource (PeoplePerHour project categories, subcategories, and median budgets) and its exact cardinality ('The 10 project categories'). It also distinguishes itself from sibling search tools by explaining that 'category is the slug search_projects and save_search take', so an agent can see how it relates to them rather than confusing it with search_projects itself.

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 a concrete use case ('a guide when pricing a proposal or a project') and positions itself as the reference source whose slugs feed search_projects and save_search. What is missing is an explicit exclusion or sequencing rule (e.g. 'call this before search_projects to resolve a category name'), but the context for when to reach for it 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 cover read-only/idempotent safety, and the description adds real behavior: sort order (most recent proposal first), returned fields per project, the meaning of counts, and the archived filter quirk. It doesn't state result-size limits or whether counts reflect the filtered set, which keeps it off a 5.

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 purpose then return shape, then pagination – good ordering with no filler. The second sentence is dense and slightly run-on (status list, fields, counts all in one), costing a little readability.

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?

Despite no output schema, the description documents the return shape (fields, ordering, counts), pagination contract, and the archived edge case. For a 3-param, fully-documented read tool, an agent has everything needed 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 coverage is 100%, so the baseline is 3; the description adds meaning above the schema by explaining cursor comes from next_cursor and null signals the last page, plus the special archived-status behavior. Query parameter is left to the schema, so it's not a full 5.

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 with explicit scope: projects 'the signed-in buyer posted'. That scoping cleanly separates it from sibling search_projects/get_project, which cover broader or single-project retrieval.

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 concrete operational guidance: 'Archived projects come back only with status archived' and 'Pass next_cursor back as cursor; it is null on the last page.' It lacks an explicit alternative pointer (e.g., use search_projects for other buyers), 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.

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

The annotations already declare this as read-only and idempotent. The description adds useful behavioral context by stating that reading does not mark anything as read, that notifications are returned newest first, and what the unread counts represent.

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 reasonably concise and front-loads the core purpose and unread counts. The second sentence elaborates on returned data and reading behavior without excessive repetition, though it is slightly long.

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 no output schema, the description needs to explain enough about the result. It does so by naming the returned notification fields and unread-count meaning, making it sufficiently complete for a zero-parameter listing tool.

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 parameter semantics are not a meaningful burden. The description appropriately focuses on return content and behavior instead of parameter documentation.

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 that it lists account notifications such as proposals, messages, and project updates, and returns unread counts. It is specific about the resource and returned content, though it does not explicitly differentiate itself from sibling list/search tools beyond the notification context.

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 implied: use this to see the latest notifications under the bell and their unread counts. It does not explicitly say when to choose this over siblings such as list_workstreams or when not to use it.

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 read-only, idempotent and non-destructive behavior, so the description correctly spends its space elsewhere: it discloses the 10-saved-searches-per-account quota and enumerates the email alert values (Never, Daily, Instantly). It omits that results may be paginated despite exposing a cursor, which is the one meaningful behavioral 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?

Two tight sentences, front-loaded with the resource and scope, followed by the returned fields and the quota constraint. No filler or repetition of the title.

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 output schema, the description carries the return-shape burden and does so by naming the fields and the alert enum values. The only shortfall is that pagination behavior (whether a cursor is always returned, page size) is left implicit.

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?

Only one parameter (cursor) with 100% schema description coverage, so the schema already defines it as the next_cursor from the previous call. The description adds nothing about the parameter, which is acceptable at this coverage level but earns no bonus.

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 a specific resource (saved project searches for the signed-in account) and states exactly what is returned: title, email alert, and filters. It distinguishes the tool from search_projects by noting the filters are inputs to that sibling rather than outputs of it.

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 implied — retrieve what the account has saved, then feed filters.query/filters.category into search_projects — but there is no explicit when-to-use versus save_search or search_projects, and no stated conditions or exclusions. The cross-reference to search_projects is the only routing signal.

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, so the safety profile is covered. The description goes beyond them with genuinely useful behaviour: only open projects are returned, closed watched projects silently drop off, and the result set changes over time — all things an agent cannot read off the annotations or 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?

Four short sentences, front-loaded with the resource and payload before the pagination detail. There is minor redundancy between the first two sentences (both restate that these are the watched open projects), but nothing is padded or off-topic.

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 two-param read tool with full schema coverage and no output schema, this is close to complete: population, return shape (by reference to search_projects), drop-off behaviour and pagination are all covered. Only an explicit routing statement against search_projects/list_my_projects 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. The description adds value beyond it by explaining the cursor/limit contract as a unit — reuse the same limit and feed next_cursor back as cursor — and by stating cursor is null on the last page, which tells the agent how pagination terminates.

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?

Specific verb plus a tightly scoped resource: 'open projects on this account's watchlist (Favourite Jobs)', with the returned fields named (budget, proposal count). It also distinguishes itself from the sibling that could be confused with it by noting the payload matches search_projects while the population is the watchlist, not a query.

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 implied rather than stated: an agent can infer this is the listing counterpart to watch_project/unwatch_project, but the description never says 'use this when you want the current watchlist' or excludes anything in favour of search_projects or list_my_projects. No prerequisites or when-not conditions are given.

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, but the description adds real context beyond them: the returned fields, the fact that replies must happen on PeoplePerHour, and the pagination termination signal (cursor null on the last page). No rate limits or auth details, so a 4 rather than 5.

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 resource and scope, then behavior, then pagination; three short sentences with no filler. There is mild redundancy between the title line and the second sentence re-describing WorkStreams, which keeps it from a 5.

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, and the description compensates by enumerating what comes back (title, link, unread count, last message with time). Combined with scope, read-only guarantee, and pagination handling, an agent has everything needed 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?

Only one parameter with 100% schema coverage, so the baseline is 3. The description earns an extra point by explaining the round-trip usage ("Pass next_cursor back as cursor") and that the cursor is null on the last page — semantics the schema alone doesn't convey.

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 (WorkStreams) plus scope: "This account's". The parenthetical "conversations with hired freelancers" defines the resource well enough that an agent can tell it apart from list_notifications, list_my_projects, or search_offers without opening another 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 frames the read-only boundary ("It reads, never sends: replying is done on PeoplePerHour") and gives pagination instructions. It does not name a sibling alternative or a when-not condition, which keeps it short of a 5.

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 only declare the generic write profile (readOnly=false, non-idempotent, open-world); the description adds real behavior: the alert goes to this account only, edits silently preserve the existing filters, and accounts are capped at 10 saved searches. The 10-search cap and the filter-immutability constraint are exactly the kind of side effects an agent would otherwise discover by failing.

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 two-mode split, and every sentence carries information (defaults, cap, filter preservation). The middle sentence is long and packs create-behavior, title, filters and alert into one run-on, which costs a point on readability.

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 9-parameter create-or-update tool with no output schema, it covers both invocation modes, what gets mutated versus preserved, who receives the alert, and the account-level quota. Nothing an agent needs to call this 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 baseline is 3; the description earns an extra point by explaining the mode dependency of parameters, i.e. that filters and query are create-only and are ignored-by-design on update. It doesn't restate the enum values or defaults, but it doesn't need to.

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 ("Save a project search") and immediately covers both modes: create with an email alert, or rename / change alert frequency on an existing search. An agent can distinguish this from list_saved_searches and delete_saved_search 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 gives the selection rule: no saved_search_id creates a new search, with saved_search_id edits the title and alert only. It also names the alternative path when filters need to change ("make a new search for other filters and delete the old one"), which routes the agent away from a misuse of this tool.

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, openWorld, idempotent and non-destructive, so safety is covered; the description adds genuinely new behavior: the exact payload fields returned, currency semantics for hourly_rate, and a precise cursor-termination contract. Missing are result-cap/pagination limits beyond the cursor rule and any rate-limit or auth expectations.

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 paragraphs, front-loaded with the resource and filters, followed by return-shape and pagination guidance. The return-field enumeration is a long run-on list that could be trimmed, but every element carries information an agent would otherwise have to guess.

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 output schema, the description takes on the burden of describing return values and does so in detail (fields, currency, About snippet), plus pagination and the hand-off to get_freelancer. It stops short of describing ordering defaults or result-total behavior, leaving mild gaps for a 7-parameter search tool.

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; the description earns above that by documenting the cross-parameter contract ('pass next_cursor back as cursor with the same limit') and clarifying that hourly_rate is evaluated in the account's currency. The rest (sort, min_rating, top_certified) is not elaborated 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 description states the resource (freelancers), the primary filter axes (skill or keyword, rate, rating, reviews, projects), and maps itself to a known external search ('same search as Hire freelancers on PeoplePerHour'). The verb is only implied by the name/title rather than written in the description, but the scope is unambiguous enough to separate it from search_projects and search_offers.

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 explicitly routes the agent to the sibling for deeper detail ('get_freelancer returns the full profile') and gives a concrete pagination procedure ('Pass next_cursor back as cursor with the same limit; it is null on the last page'). It does not state when to prefer this over search_projects/search_offers or any preconditions, so it falls short of the 5 bar.

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, so the safety bar is low; the description adds real value beyond that by enumerating the returned fields and disclosing the termination signal ('it is null on the last page') plus the stable-limit paging rule. It omits auth or rate-limit context, which keeps it from a 5.

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?

Purpose is front-loaded in the first sentence, then return fields, then the sibling pointer, then pagination — a clean priority order with no filler. Even the historical note ('once called Hourlies') earns its place by mapping older terminology to the resource.

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 output schema, the description carries the return-value burden and does it: it lists the fields returned and explains how to know when paging ends. Minor gaps remain (no mention of total result counts or ordering of the returned list beyond the sort param), but nothing needed to call 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 baseline is 3, but the description adds meaning beyond it — price is denominated in your account currency (relevant to interpreting price_range and the returned price), and the cursor/limit pairing is framed as a paging contract rather than two independent fields. Slight overlap with the schema's own 'keep it the same across pages' note keeps it at 4.

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 ('fixed-price Offers freelancers sell, by keyword or price') and immediately scopes what it returns: sales, rating, seller. It also names the sibling it is not — get_offer returns description, add-ons and images — so an agent can distinguish the list-search from the detail-fetch without 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?

Explicitly routes the agent: use this for searching, use get_offer for description/add-ons/images, and gives the pagination protocol (pass next_cursor back as cursor with the same limit; null on the last page). It does not contrast against the other search siblings (search_projects, search_freelancers), but the fixed-price framing makes the boundary inferable.

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 read-only, open-world and idempotent, yet the description still adds substantial behavior: results are newest-first, 'times are UTC', next_cursor is null when exhausted, no matches exist, and one call scans at most 200 newest projects with 'since', which explains the key trap (a short page that still has a next_cursor).

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 what it returns and its ordering, then filters, then pagination — a sensible order. It loses a point for redundancy: 'newest first' appears in both the first and second sentences, and the opening two sentences retread the same ground.

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 output schema, the description carries the return-value burden and does it: budget type and currency, category, proposal count and brief start, plus a full pagination contract. Nothing an agent needs in order to page or poll 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 baseline is 3, but the description genuinely extends it: 'cursor' is tied to next_cursor from the previous call, 'since' is framed as the polling watermark, and 'limit' is qualified by the scan cap. Some of the field talk (budget.type, freelancer_country) describes return values rather than parameters, which reads as slightly off-register but is not misleading given there is no output 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?

Names a specific verb and resource ('open projects buyers posted', 'newest first') and immediately scopes it against the Jobs page search. The description of returned fields plus the explicit handoff to get_project for the full brief lets an agent distinguish it from search_freelancers and search_offers without opening a 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?

Gives concrete usage context: poll with 'since' to read only new postings, and use get_project when the full brief is needed. It doesn't explicitly rule out search_offers or search_freelancers, but the resource distinction is clear enough that no agent would confuse them.

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 destructiveHint=true, openWorldHint=true and idempotentHint=false, so safety framing is covered. The description adds one genuinely useful behavioral fact — no notifications are sent to others ('Nobody else is told'). It does not say what happens if the project is not on the watchlist (error vs no-op), which matters 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?

Two short sentences, front-loaded with the action and followed by the one piece of behavioral context an agent can't get from structured fields. No 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?

For a single-parameter, non-idempotent mutation with no output schema, the definition covers what is removed and who is affected. The only real gap is failure behavior when the project is not currently watched.

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 schema already explains that project_id comes from list_watchlist or the project URL. The description adds nothing further about the parameter, so the baseline of 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?

States a specific verb+resource ('Take a project off this account's watchlist') and immediately narrows scope to the signed-in account's watchlist. The counterpart sibling watch_project is obvious from the verb pairing, though it is never named 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?

Usage is implied by the account-scoped phrasing, and the pointer in the schema to list_watchlist gives a source for the ID. However, there is no explicit 'use this instead of X' guidance and no stated precondition (e.g., project must currently be watched).

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?

Adds context beyond annotations: buyer is not notified, already-watched calls are no-ops (reinforcing idempotentHint with concrete semantics), and the account-scoped nature of the adding. Missing auth requirements or failure modes, but the annotation set is already rich.

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, front-loaded with the action and purpose, followed by behavior and then navigation pointers. 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?

One-param mutation tool with full annotations but no output schema; the description covers purpose, notification side effect, idempotence semantics, and sibling routing. Only return-value/error behavior is unaddressed, which is minor here.

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 single parameter is documented with a useful note about sourcing it from search_projects or the URL. The description itself adds nothing param-specific, so 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?

Specific verb+resource ('Add a project to this account's watchlist'), plus a concrete user-facing alias (Favourite Jobs / 'the heart on the project page'). Clearly distinguished from siblings list_watchlist and unwatch_project by name.

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 states what happens when already watched ('changes nothing') and names the read/remove siblings for alternative intent. No explicit prerequisites or exclusions beyond that, but the when-to-use is clear.

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