Worklittle Jobs

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

Annotations only give readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description adds substantive context beyond them by disclosing that Worklittle performs the application in a browser and actually submits it — a real, externally visible action. It does not state irreversibility, auth/credential requirements, or interaction with auto_submit, which is noted only in the 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 tight sentences, front-loaded with the core purpose and the browser-automation behavior, then the required input and the conditional extra fields. No filler, though the conditional clause is the misleading one.

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 values need no explanation, and annotations carry the safety profile. However, for an irreversible real-world action the description omits auth/account prerequisites, the role of auto_submit, irreversibility, and it references parameters ('name', 'email') absent from 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 coverage is 100%, so the baseline would be 3, but the description introduces fields that do not exist in the schema ('also include name, email and resume'), which can lead an agent to attempt unsupported arguments. The only accurate addition is the provenance of job_id, which the schema already states.

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 ('Apply to a job for the user') and explains the mechanism: Worklittle fills out and submits the application in a browser. It clearly differs from siblings like stop_application and check_application_status, though it only names search_jobs as an input source rather than contrasting the sibling set.

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 job_id comes from ('Pass job_id from search_jobs'), which is useful pre-call guidance, but does not say when to use this over alternatives such as track_applied_job, nor any prerequisite state (profile, resume, connected account). Usage is implied rather than specified.

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 description adds genuinely load-bearing semantics beyond the annotations: it defines what the 'completed' status actually means ('it was submitted') and reveals the payload shape (status, filled fields, live view link). The readOnlyHint=false on a tool called 'Check' is not explained, but the added status semantics and return contents are real value.

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 domain and action, then the status semantics. Nothing is padded or repeated from the title or 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?

An output schema exists, so return values need not be explained, yet the description helpfully summarizes them and clarifies the ambiguous 'completed' status. Gaps remain around failure modes (invalid or expired session_id) and whether repeated calls have side effects given readOnlyHint=false.

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% and session_id is never mentioned in the description, so the parameter's meaning and header-based passing are undocumented there. The description does at least frame the call as targeting one application (session-scoped), which partially compensates, but a 3 is the ceiling for a fully undocumented identifier.

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 pairs a specific verb ('Check') with a specific resource ('an application Worklittle is filling out') and even enumerates the returned data (status, filled form fields, live view link). It distinguishes itself implicitly from the listing sibling (list_active_applications) by scoping to a single application, though it never names an alternative 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 explicit when-to-use or when-not-to-use guidance, and no sibling tool is named (list_active_applications, apply_for_job, track_applied_job all sit nearby). The phrase 'an application Worklittle is filling out' implies the context of an in-progress application, but the agent must infer that alone.

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, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that profile — no statement that the deletion is irreversible, whether a confirmation step exists, or what happens to applications tied to the resume.

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 the verb and scope first and no filler. The 'Jobs —' prefix is slightly redundant with the title, which keeps it out of 5 territory.

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 and no parameters are needed, so the description only has to convey the target of the deletion, which it does. For an irreversible destructive action, a note about reversibility would have made it fully 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-parameter tool is 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 (delete) and resource (the user's saved resume), which cleanly separates it from the read/upload siblings get_my_resume and upload_my_resume. It does not explicitly name those siblings, so it stops short of 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?

There is no when-to-use guidance, no prerequisite (e.g. must a resume exist), and no mention of confirmation or alternatives such as re-uploading. The agent is left to infer usage entirely from the verb.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the query fallback 'loads the first matching live listing,' which tells the agent the result is a non-deterministic first-match rather than a ranked set. It does not discuss the summary/AI-generation path, though the schema covers that.

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 core purpose, then the two resolution paths. The example clause is slightly verbose but earns its place by disambiguating the query path.

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 values need no explanation, and the description covers the calling decision fully. The one gap is silence on when to set summary=true for first-time AI generation, which matters for a tool whose default is raw-plus-cached-only.

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 all four parameters including the summary generation flag. The description adds the job_id-vs-query precedence relationship, but that overlap is largely restated by the schema's own 'used when job_id is missing' note, so baseline 3 fits.

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 detailed information about a specific job') and enumerates the payload (responsibilities, qualifications, company details), which separates it from the listing-oriented search_jobs sibling it explicitly names.

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 explicit routing rules: pass job_id from search_jobs when available, otherwise pass query plus optional location, with a concrete example ('the first software engineer job in Austin'). The two paths and the condition selecting each are spelled out rather than left 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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds real behavioral context beyond annotations: what each mode returns and the caveat that salary signals come only from 'listings that publish pay', which warns the agent about partial data.

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, all front-loaded: purpose first, then the no-arg mode, then the filtered mode. Every sentence carries distinct information with no 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?

An output schema exists, so return-value detail is not required, and annotations cover safety. The description covers both invocation modes and output content; the only gap is that the optional workplace_type filter is 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 100%, so the schema already documents query, location, and workplace_type with examples. The description reinforces query/location semantics (role, city) and the no-arg default but never mentions workplace_type, so it adds only marginal value over 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 a precise verb and resource ('Returns aggregate job-market statistics') and immediately clarifies the two operating modes (full indexed market vs. filtered slice). It is clearly distinct from siblings like search_jobs, which returns individual listings rather than aggregates.

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 says when to call with no args and when to pass query/location, with a concrete example ('product managers in San Francisco'). It does not name alternative tools (e.g. search_jobs) or state exclusions, so it stops short of full 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds genuine behavioral context beyond that: the connected=false signal for unlinked accounts and the set of fields returned. Return format needn't be explained since an output schema exists.

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 the primary purpose front-loaded and the edge-case fallback immediately after. No filler or restatement of the tool name.

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 zero-parameter read tool with annotations covering safety and an output schema covering the response shape, the definition supplies everything an agent needs: what it returns, and how to handle the unlinked-account state. Nothing material 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 takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate and it introduces no spurious parameter language.

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 ("Get the user's Worklittle profile") and enumerates the returned fields (name, location, contact details, job preferences), so an agent knows exactly what this retrieves. It routes to siblings for the unlinked-account case but does not explicitly contrast with update_my_profile, so distinguishing from every sibling is left implicit.

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?

Provides a clear conditional: if the account is not linked the tool returns connected false, and the agent should instead use get_my_resume or apply_for_job to sign in. That is actionable routing, though there is no explicit statement of when not to use get_my_profile (e.g., versus update_my_profile).

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral value beyond them by disclosing a status state machine (ready/processing/missing) and that resume text is only present when ready.

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 what is returned and followed by the use case. Every clause carries information; nothing is redundant or padded.

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 detail the return shape, and it still usefully summarizes the status values and conditional content. Minor gaps remain around auth/account prerequisites and what happens for a 'missing' resume, but nothing critical is absent.

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 takes zero parameters, so the baseline is 4. There are no arguments whose semantics need explaining, and the description correctly does not invent any.

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 (get the user's saved resume) and even enumerates the returned status values (ready, processing, missing). It is clearly a read of the user's own resume, distinct from upload_my_resume/delete_my_resume, but it never names those siblings to make the boundary 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?

"Use it to tailor advice or an application to the user's real experience" gives a concrete when-to-use condition. It stops short of stating when not to use it or pointing at an alternative (e.g. get_my_profile) for profile data.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real value by enumerating which application states are returned and disclosing that identifiers (job_id, session_id) come back, which is beyond the annotations.

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 with no filler: the scope statement is front-loaded and the usage hint follows. Every clause earns its place, and nothing is repeated from the annotations or 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?

An output schema exists, so return values need not be spelled out, and the description covers scope and intent adequately for a zero-parameter list tool. Minor gap: no note on result volume, ordering, or emptiness handling, which would help an agent interpret an empty list.

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 takes no parameters, so the baseline is 4. The description appropriately mentions returned identifiers rather than inventing parameter semantics, and there is no parameter ambiguity to resolve.

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 ('List the user's applications') and narrows scope precisely to those currently being filled out, enumerating the three relevant states (queued, running, waiting on the user). An agent can distinguish this from check_application_status or list_recent_chats without opening any 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 says 'Use it to find which one to stop or check,' which routes the agent toward stop_application and check_application_status. It gives clear when-to-use context but does not name the alternative tools directly or state any exclusion 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the returned fields (title, status) but says nothing about pagination behavior, ordering, or auth requirements beyond the schema's cursor hint. With annotations carrying the safety burden, a 3 is appropriate.

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 efficient sentence with the resource and scope front-loaded and zero filler. Slightly terse but nothing wasted.

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 tool is a simple two-param read with an output schema, so return values need not be explained in the description. The behavior is adequately covered for a low-complexity 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?

Schema description coverage is 100%, so both limit and cursor are fully documented in the schema. The description adds no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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 (List) and resource (user's recent Worklittle chats) and even names the returned fields (title and status) and the intended consumer (app sidebar). It is clear without needing sibling differentiation, since no other sibling lists chats.

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 phrase 'for the app sidebar' hints at context but gives no explicit when-to-use rule, no exclusions, and no alternatives. An agent gets no guidance on how this differs from, say, searching or filtering chats.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it doesn't say whether the session is invalidated server-side, whether other devices are affected, or what the user state becomes afterward.

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 short sentence that is front-loaded with the action. The 'Business —' prefix is wasted space that duplicates the title, but the core sentence is tight and unambiguous.

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 zero-parameter tool with an output schema, the description is nearly sufficient; the output schema covers return values. The phrase 'in this app' usefully scopes the logout, though the absence of any prerequisite or session-scope detail leaves a minor gap.

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 takes zero parameters, so the schema carries no parameter burden. Per the baseline for a 0-parameter tool, a 4 is appropriate since there is no semantic gap for the description to fill.

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 and resource — 'Sign the user out' — so an agent knows exactly what the tool does. There is no sibling that performs authentication or session termination, so sibling differentiation isn't strictly required, but the 'Business —' prefix is redundant filler that adds no distinguishing information.

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 offers no when-to-use guidance, no prerequisites (e.g., must be logged in), and no mention of alternatives or conditions under which logout is inappropriate. It only restates the 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 declare this is not read-only and not destructive, so the agent knows it creates state; the description adds the useful fact that the artifact is a sign-in link valid for opening chats on worklittle.com. However, for a security-sensitive session-minting tool it omits key traits: link lifetime/expiry, single-use behavior, required auth, and whether prior sessions are invalidated. Adequate but thin beyond the annotations.

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 with the outcome front-loaded and no wasted clauses. The 'Business — ' title prefix is redundant with the tool's title metadata but costs little.

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 that documents the returned link, the core contract is covered. Still, an agent calling a session-minter would benefit from knowing about expiry, one-time use, and auth requirements, none of which appear in the description.

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 takes zero parameters and schema coverage is 100%, so the schema baseline of 4 applies; the description adds nothing parameter-related, nor does it 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?

The description gives a concrete verb and artifact ('Create a sign-in link') plus the consumer and destination ('the Worklittle app ... worklittle.com'), so an agent understands the outcome. It is clearly distinct from siblings like list_recent_chats or logout_connected_account, though it never explains what the created link is or how it is used.

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 guidance, no prerequisites, and no mention of alternatives or the conditions under which a session link should be minted. The clause about opening chats describes intent, not invocation criteria.

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 description adds useful behavior beyond the annotations (storage location, overwrite semantics, the warning that old text is lost unless merged). However, the input schema and description both state the value 'replaces the old text' — a destructive overwrite of existing data — while destructiveHint is declared false. That mismatch can mislead an agent about the reversibility/risk of the call.

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 and every clause carries weight (content scope, storage target, merge prerequisite, authoring constraint). The opening sentence is long and list-heavy, which slightly dilutes readability, but there is 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?

Given one parameter, full schema coverage, an output schema, and annotations, the description covers purpose, storage, prerequisites, and tone. The only meaningful gap is the unresolved conflict between the 'replaces the old text' semantics and destructiveHint=false, which leaves the agent's risk model ambiguous.

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 baseline is 3, and the description earns above that by explaining what the string should contain (visa sponsorship, relocation, notice period, salary, languages, self-identification, etc.) and how to populate it (merge from get_my_profile, use the user's own words). This adds real meaning over the schema's terse 'full More about you text'.

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 (save) and resource (standing facts about the user / the 'More about you' settings text) and explains the downstream effect (used by Apply with AI on every future application). It enumerates concrete content categories, making the tool's remit unmistakable. It only lightly differentiates from siblings, naming get_my_profile as the read counterpart rather than explicitly contrasting with update_my_profile.

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 an explicit prerequisite workflow: 'read get_my_profile first and merge with what is there, so nothing is lost,' which tells the agent when and how to prepare for this call. It also constrains authoring ('write it in the user's words; never invent facts'). No explicit when-not or alternative-tool routing is provided, 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 cover safety (readOnly, non-destructive, openWorld), and the description adds real value beyond them: it discloses the index only contains employers with open jobs, what fields come back, and the required zero-result handling. It doesn't discuss ranking behavior or rate limits, but the critical behavioral constraint is present.

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 and return fields before routing and fallback instructions. Slightly long with three sentences of fallback guidance, but each sentence carries actionable instruction rather than 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?

With annotations, a 100%-covered schema, and an output schema, the description only needs to add routing and edge-case behavior — which it does, including zero-hit recovery and the anti-hallucination rule. Nothing an agent needs 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 description coverage is 100%, so both q and limit are fully documented in the schema (length bounds, default 5, max 20). The description only restates that querying is by name or slug, adding 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?

States a specific verb (Search) and resource (Worklittle market company index) with scope (by name or slug, ranked typeahead), and implicitly separates itself from search_jobs by framing the result as input to job search rather than job search 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?

Explicitly names the trigger ('Use when the user names an employer and you need a real slug/id') and the downstream uses (search_jobs company= filters, job alerts, automations). It also gives fallback guidance for zero hits and an explicit prohibition on inventing ids/slugs.

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 and non-destructive, so the bar is met, yet the description adds substantial behavior: search is anonymous and no OAuth is needed, the map recenters on the place, default recency is 7 days, the 7-day default is suppressed when visa_sponsorship is set, and include-company zero-result handling. These are operationally important traits not present in 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?

Purpose and the place/role split are front-loaded well, and most sentences govern correct invocation. However, it is long and repetitive (the leading-dash negative rule and 'never merge titles into one query' are restated multiple times), and it devotes space to post-render reply phrasing ('never mention swiping') that does not help tool selection.

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 18 optional parameters, an output schema, and open-world annotations, the description supplies the missing operational layer: field separation rules, geo vs. text location strategy, filter availability and its absence (no salary/remote/benefits filter), filter conservatism, and pagination via cursor. Nothing needed to call it correctly appears to be 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% (baseline 3), but the description goes well beyond it: place and role must be separate fields, radius 25-50 km for a city, recency words map to posted_within_days values (1/3/7/14/30), company takes bare lowercase slugs with leading-dash exclusion, and title negatives use the same dash convention. This meaningfully reduces mis-invocation risk on an 18-parameter tool.

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 states a specific verb and resource ('Opens the Worklittle jobs MAP for a place and an optional role') and immediately disambiguates it from a listing tool ('This is a map query, not a list of jobs'). It also distinguishes itself from siblings like search_companies and apply_for_job, so an agent can route correctly 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?

Explicit when-to-use ('Call it whenever they want Worklittle jobs'), when-not to call apply/connect, and named alternatives for the same intent: near_lat/near_lng + radius_km over location substring, location_or for multi-metro instead of near_*, one broad call over many for umbrella phrases. It also prescribes fallback behavior when an include-company filter returns 0.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely new context: it works while the application is running, ready to submit, or waiting for answers, and it constrains input ('never add facts'). It stops short of saying whether a change is reversible or how it interacts with an in-flight submission, so it falls just short of full transparency.

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 operation and its condition, then prerequisites and the save_about_me pointer. The parenthetical examples are somewhat heavy but each maps to a real distinct use case rather than 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?

An output schema exists, so return values need no explanation. With the trigger condition, validity window, session_id provenance, input constraints, and the persistent-facts alternative all present, an agent has everything required to invoke this 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 50% — only 'instructions' is described in the schema. The description compensates by stating where session_id comes from (apply_for_job or list_active_applications) and by defining the expected content of instructions (plain words, user's exact facts, no invented facts). That is meaningful added semantics 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?

States a specific verb and resource ('Change what an application in progress fills in') with an explicit scope qualifier ('without stopping it') that separates it from stop_application and apply_for_job. The title/name pairing plus the concrete examples make the operation unambiguous.

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 exact triggering condition (the user says something about an application filling right now) plus four quoted utterances that map to it, and names an alternative path (save_about_me) for facts meant to persist. An agent can decide when to call this 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 declare destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds value beyond that by stating the effect is permanent – the application cannot be resumed and the user must start over – which is exactly the consequence an agent needs before calling a destructive 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?

Three short sentences, front-loaded with the action, then the irreversible consequence, then the prerequisite. Every sentence earns its place and nothing is padded.

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 values need not be explained. For a one-parameter destructive tool the description covers action, irreversibility, and provenance of the session_id; it leaves unstated what happens if no application is in progress or if the session_id is stale.

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 0% and the single session_id parameter is required, so the description carries the burden. It usefully names the two sibling tools that produce a session_id (apply_for_job, list_active_applications), which is more than the schema provides, though it doesn't state the identifier's format or that it is passed as the Session-Id header.

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 ('Stop') and resource ('an application that Worklittle is filling out for the user'), which cleanly separates it from siblings like delete_my_resume, apply_for_job, and check_application_status. An agent can route between stop_application, list_active_applications, and apply_for_job without inspecting 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?

Gives the prerequisite for use – the session_id must come from apply_for_job or list_active_applications – which tells the agent both when this tool applies and what must precede it. It stops short of explicit when-not-to-use guidance or contrast with a sibling cancel/resume tool, 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 readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that the tool can either add or mutate status (an upsert), which is useful, but it omits auth/permission needs, what happens on duplicate tracking, or side effects of status changes.

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 that names the resource and the two core actions with no filler. It is appropriately sized, though slightly compressed given the tool's branching behavior.

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 values need not be explained, and annotations cover safety. However, for a 6-parameter mutation with branching semantics (add vs. status change), the description leaves the trigger conditions and edge behavior underspecified.

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 67%, and the schema itself richly documents method and status with enums and defaults. The description's mention of 'Applied or Saved list' loosely maps to status values but adds no syntax or default detail beyond the schema, so baseline 3 is appropriate.

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 clear verb+resource ('Add a job to the user's Applied or Saved list, or change its status') and captures the upsert nature of the tool. It does not, however, explicitly differentiate itself from close siblings like apply_for_job or list_active_applications.

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 phrase 'so they can find it later' implies the intent (tracking for later reference), but there is no explicit when-to-use guidance or contrast with apply_for_job, which is the most likely confusion point. Usage is only implied.

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 disclose the mutation profile (readOnlyHint=false, destructiveHint=false), so the description's main added value is the partial-merge behavior. It omits clearing semantics (empty string vs profile_clear_fields) and any auth or validation requirements, so it adds only modest context.

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 the most important constraint. The "Jobs —" prefix is redundant with the title, but otherwise there is no waste.

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 20-parameter mutation tool with 15% schema coverage, the description is thin: it does not explain how fields are cleared, what the field-naming convention means, or required-vs-optional behavior. The output schema covers return values, but the input-side guidance is far from 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?

With 20 parameters and only 15% schema-description coverage, the description must carry the load, but it only names broad categories (name, phone, links, job kind). Non-obvious field names like you_name, you_work, you_school, you_interests, and profile_clear_fields are left unexplained, and the clearing/overwrite distinction is unaddressed.

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 (Update) and resource (the user's Worklittle profile) and enumerates representative fields (name, location, phone, links, job kind). The verb cleanly separates it from the read-side sibling get_my_profile, though neither sibling is 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?

"Only send the fields to change" gives useful partial-update guidance, implying usage. However, it never states when to use this versus get_my_profile, whether reading first is recommended, or how to remove a value as opposed to changing one.

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, destructiveHint=false, and openWorldHint=false, so safety posture is covered. The description usefully adds accepted formats (PDF, Word, text or image) and the destination profile, but omits whether an upload replaces an existing resume or how it interacts with the separate delete_my_resume 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?

A single front-loaded sentence that states the action, the source, the destination, and the required parameter with zero 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?

With an output schema present and annotations covering the safety profile, the description covers the essential call mechanics. It is only short of fully complete because replacement/duplicate-resume behavior for a mutation tool is left unstated.

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 baseline is 3, and the description earns an extra point by explicitly directing the agent to pass the attached file as resume_file, disambiguating it from the other three optional parameters (mime, filename, content_base64).

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 (Save), resource (the resume the user attached in chat), destination (their Worklittle profile), and downstream purpose (so it can be used to apply). This clearly distinguishes it from get_my_resume and delete_my_resume 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 implies the usage context (a file attached in chat, to be used later for applications) and names the primary parameter to pass. However, it never states when to use this versus get_my_resume or what to do if a resume already exists, so the guidance remains implicit.

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