TCI Job Finder

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the response includes the job page link and a link to the official advert for applying, which is useful content-level context, but says nothing about missing/expired jobs or error 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?

Two compact sentences, front-loaded with the core action and the identifying input. The second sentence adds return-content value without 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 read tool with annotations covering safety and no output schema, the description covers purpose, input provenance, and a hint at return contents. Complete enough to invoke correctly, though error/empty-result behavior 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?

Schema description coverage is 0%, but the single parameter is structurally constrained by a pattern in the schema. The description adds provenance ('from search_jobs') which helps an agent obtain a valid value, but does not explain the slug format or what happens on a bad slug.

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 full details of one current job') with scope ('current') and identifies the slug source as search_jobs, which distinguishes it from the listing sibling. Clear enough to act on 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?

Usage is implied rather than stated: the parenthetical '(from search_jobs)' hints that this is a follow-up to a search, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of list_employers or hiring_report_stats.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely useful context by enumerating the returned aggregates and noting the link to the full report, but it says nothing about behavior for unavailable months or error conditions. With annotations already carrying the safety burden, this is adequate but not 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?

The description is a single front-loaded sentence that leads with the resource and then lists outputs, with no filler. The field enumeration is slightly encyclopedic but each item conveys what an agent will get back, so it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-optional-parameter, read-only report tool with a fully documented schema, no output schema, and annotations covering safety, the description supplies enough: what it returns, that a link to the full report is included, and how the default month resolves. Only the behavior for a month with no published report is unspecified.

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%: the single month parameter is documented with a YYYY-MM pattern and an example. The description only restates the default ("Defaults to the latest report"), which is already in the schema, and adds no format or edge-case detail beyond that. Baseline 3 is appropriate when the schema does the full job.

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 (the monthly Turks and Caicos Hiring Report on tcijobfinder.com) and enumerates exactly what figures it returns: open jobs, employers, Government vs private share, jobs by island and industry, top employers, salary disclosure. That is clearly distinguishable from the sibling tools get_job, list_employers, and search_jobs, which operate on individual records or search results rather than an aggregate report.

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 notes that the month parameter defaults to the latest report, which implies the tool's primary use case, but it never explicitly says when to reach for this aggregate-report tool instead of search_jobs or list_employers, nor does it state any exclusion. The usage context is inferable from the content list rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the return shape (job counts and a link), but says nothing about ordering, the default cap of 50, or how employers with zero current vacancies are treated relative to the stated scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with no filler; the territory scope and what comes back are packed in without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully names what is returned, and all three optional params are fully documented in the schema. Only minor gaps remain: result ordering and whether the 'current vacancies' premise can be relaxed.

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 each parameter carries its own description plus enums for island and category, so the schema does the heavy lifting. The description adds no filtering semantics beyond 'with current vacancies' – it doesn't indicate that island/category narrow the list or how the two filters combine. 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?

States a specific verb and resource ('list employers') scoped to a region and to those with current vacancies, and even previews the payload (open job counts, link to jobs). It never names a sibling, but the resource itself cleanly separates it from get_job, search_jobs, and hiring_report_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the browse-by-employer path versus search_jobs' per-posting search, but the description never states when to pick this over a sibling or any exclusion. No prerequisites or pagination guidance either.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely useful behavior: results come back newest-first and each result only links to a tcijobfinder.com page that in turn leads to the official advert — telling the agent it will not receive application-level detail directly.

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, no filler: scope and ordering come first, then the result-link behavior. Every clause carries information an agent can act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search with no output schema, the definition covers scope, ordering, filtering optionality and what the results point to. It stops short of describing page-size defaults or how many pages are reasonable, but the schema handles limit/offset adequately.

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% with enums enumerated and defaults documented, so the schema carries the parameter burden. The description only adds that everything is optional, which is a marginal addition over the schema's zero required fields.

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 (current, open job vacancies) with geography and implicit ordering (newest first). It is clearly distinguishable from get_job, list_employers and hiring_report_stats by the plural listing of vacancies, though it never names a sibling to route the agent 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?

"All filters are optional" is the only usage guidance, giving implied context that this is a browse/query tool. It never says when to prefer get_job for details or list_employers for employer-centric lookups, so the agent must infer the split from names alone.

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