Seoulstart

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value by disclosing the data source (MOLIT reported contracts) and that figures are medians, but says nothing about data recency or how missing/thin markets are handled.

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: the what-and-source first, the when-to-use second. No filler, and the resource list 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 100% schema coverage and no output schema, the description correctly states what the comparison returns (rent, jeonse deposit, sale price) and where the data comes from. Only the time window of the underlying contracts and the output shape are 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?

Schema coverage is 100%, so both required areas, the optional province qualifiers and the property_type enum are already fully documented with examples. The description adds no parameter-level guidance beyond what the schema provides, which is the baseline case for full coverage.

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 — median monthly rent, jeonse deposit and apartment sale price compared side by side for two areas, sourced from MOLIT reported contracts. The 'two areas' framing implicitly distinguishes it from housing_median and housing_trend, but no 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?

"Use it when someone is choosing between two districts or cities" gives a clear situational trigger. It stops short of exclusions or naming housing_median/housing_trend as the alternative for single-area or time-series lookups.

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, non-destructive, idempotent and closed-world, so the safety profile is covered. The description adds genuinely new context by disclosing the data provenance (reported contracts, MOLIT) and the return shape (median, contract count, month). Residual ambiguity is how the contract count should be used as a confidence signal, which is only loosely implied.

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: what it returns, when to use it, what comes back. No preamble or repetition, and the resource definition is front-loaded before the usage hints.

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 steps in to state the returned fields, and the provenance and unit conventions are adequate for a read-only lookup tool. All six parameters, including the province disambiguation rule and the 12-month limit, are covered by schema or 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?

Schema coverage is 100%, so every parameter, enum and default is already documented in the schema. The description's mention of monthly rent vs jeonse vs sale echoes the transaction enum without adding syntax or edge-case rules. Baseline 3 is correct since 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?

The description names a specific verb-and-resource combination: median monthly rent and deposit, jeonse deposit, or apartment sale price for a South Korean area, sourced from reported MOLIT contracts. That is far more precise than the title alone. It does not explicitly distinguish itself from siblings like housing_compare or housing_trend, but the singular 'median in an area' framing implies a point estimate rather than a comparison or time series.

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 three concrete triggering questions (what rent costs in a Seoul district, how big a jeonse deposit is, what apartments sell for), which is strong positive guidance. It offers no exclusions or named alternatives, so an agent must infer that housing_trend or housing_compare should be used for time series or side-by-side requests.

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, non-destructive and closed-world, so the safety profile needs no restating. The description adds real value beyond them: the data source (MOLIT reported contracts), the geographic scope (nationwide plus Seoul), and the exact metric set returned. It stops short of noting datapoints like reporting lag or whether renewed-lease figures are seasonally adjusted.

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 with no filler: the first front-loads what comes back, the second front-loads the use case. The metric list is dense but every element is distinct 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 parameters and no output schema, the description must carry the return content itself, and it does — enumerating the metrics and the geographic scope. It is largely sufficient for an agent to decide whether to call it, with the main residual gap being no explicit routing guidance against the median/trend/compare siblings.

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?

Zero parameters and 100% schema coverage, so there is nothing for the description to compensate for. The baseline of 4 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 the concrete resource (reported housing contracts from MOLIT) and enumerates the specific metrics returned: median monthly rent, jeonse deposit, apartment sale price by home type, renewal increases, and jeonse-to-sale ratio. Scope (nationwide and Seoul) is explicit. It doesn't explicitly contrast itself with housing_median or housing_trend, but 'summary' and 'quick overview' do signal an aggregated snapshot versus those 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?

The single guidance sentence — 'Use it for a quick overview of the Korean rental market' — gives the intended context, but there are no exclusions and no named alternatives. With three closely related siblings (housing_compare, housing_median, housing_trend) an agent must infer on its own when to reach for this one instead of 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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real context beyond them: the data provenance (MOLIT reported contracts), the time window (last year) and the monthly granularity of the medians. It stops short of describing pagination or result shape, 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?

Two sentences, front-loaded with what is returned and at what granularity, followed by the usage trigger. Nothing is repeated from the title or schema, and every clause carries 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 only two well-documented parameters, no output schema and rich annotations, the description supplies the missing return-shape information: three median measures reported month by month over a one-year window. Only the response structure and any result-size limits remain 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%, with area and province both documented in detail including Korean-language examples. The description adds only that the area is "an area of South Korea," which does not extend the schema's meaning, 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?

States a specific verb and resource: month-by-month median apartment rent, deposit and jeonse deposit for a South Korean area over the last year, sourced from MOLIT reported contracts. An agent can tell this is a trend/time-series read rather than a single-value lookup, though it never names housing_compare or housing_median to sharpen the boundary.

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 an explicit trigger: "Use it when someone asks whether rent is rising or falling in an area." That covers the when-to-use case clearly, but there are no exclusions or named alternatives for adjacent questions like comparing two areas or getting a single median.

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, closed-world, non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses the return shape ('counts and the date of the newest listing, no job names'), which prevents an agent from expecting a listing payload.

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-loads the core capability, then usage, then return shape — a sensible information order. The middle sentence is long and enumerates dimensions with some redundancy, but every clause describes a real facet of the output.

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 results and does so ('counts and the date of the newest listing, no job names'). An agent has enough to call it and interpret the response, though exact field names or count granularity are 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. The schema already enforces an empty object with additionalProperties false.

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?

Opens with a specific verb and resource ('Counts of the open jobs on Seoulstart Jobs') and immediately enumerates the exact breakdowns returned. This clearly separates it from siblings like search_jobs, which returns individual listings rather than aggregate counts.

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 triggering questions ('how many English-speaking jobs there are in Korea, or which visa routes and roles are common'), which is strong positive guidance. It does not explicitly name search_jobs as the alternative for per-job results, so the exclusion side is left implicit.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavior: what each result contains and an output obligation ("Always share each job's Seoulstart link"), plus the note that Korea jobs carry inferred Korean-level and visa-route data. It stops short of stating pagination or result-cap 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?

Front-loaded with scope and return contents, then use cases, then the link-sharing rule — a sensible ordering. It is dense but every sentence contributes; only the field enumeration overlaps slightly with the schema's own descriptions.

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 compensates by listing the returned fields and the extra Korea-specific annotations. All six optional parameters are covered by the schema, use cases are given, and the link-sharing requirement is stated — 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% and three enums are fully documented in the schema, so the schema does the heavy lifting. The description only indirectly reinforces semantics by noting that Korea jobs carry Seoulstart's read of Korean level and likely visa route, which hints at what the korean/visa_route filters are derived from, but adds no syntax or defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Search open jobs") plus a precise scope: jobs in South Korea for foreigners on visas, remote, global, and AI training work. It even enumerates the return fields, so an agent knows exactly what comes back. It does not name jobs_overview or explain how it differs from that sibling, 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?

Gives concrete trigger cases: "jobs in Korea, English-speaking jobs in Seoul, jobs with visa sponsorship in Korea, D-10 or E-7 jobs, or AI training gigs" — this maps directly onto the market and visa_route filters. No explicit when-not or routing to jobs_overview/visa_sponsoring_companies, so it is clear context without exclusions.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-structured context: the upstream source URL, how ranking is computed, and the important reliability caveat that a mention is a strong sign rather than a promise. It does not describe return shape, but with no output schema that is a minor 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?

Three sentences, front-loaded with what the list contains and how it is ranked, followed by provenance and the caveat. Every sentence carries information; the only minor slack is that the source URL restates what the tool name and context already imply.

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-optional-parameter read-only list tool with no output schema, the description covers scope, ranking, data source, and reliability. What an agent still cannot tell is the shape of each returned employer record (name only, or name plus counts and links), which is the one thing a no-output-schema tool would benefit from stating.

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 both parameters (limit, include_teaching) are fully documented in the schema including defaults and bounds. The description adds nothing about parameters, so the baseline 3 applies — the schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (employers in South Korea with open jobs on Seoulstart) and the qualifying criteria (visa-sponsorship mentions or E-7-typical professional roles), plus the ranking basis. It is clearly a company list rather than a job search, which implicitly separates it from search_jobs and jobs_overview, but it never names those siblings to make the distinction 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?

Usage is implied: this is the tool for finding employers that sponsor visas, and the closing sentence tells the agent the data is a signal, not a guarantee. There is no explicit statement of when to prefer search_jobs or jobs_overview instead, nor any prerequisite or exclusion, so the agent must infer routing.

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