Georgia Prisoners' Speak Public Data

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds substantial value beyond that: the verbatim-source caveat ('GDC's wording verbatim', 'narrative is GDC's own text'), the data provenance and volume, and notably the naming/redaction behavior ('Structured rows name staff, officers and contract staff as GDC printed them; other people appear by category and role only'). These are exactly the kind of behavioral traits an agent cannot infer from annotations alone.

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 dense but each sentence earns its place: source/scope first, then row structure, then filters with examples, then the naming caveat. It is a single block rather than segmented, but the logical flow is strong and there is no filler or repetition of what annotations already state.

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 tool with eight optional parameters and no output schema, the description covers the dataset, row granularity, fields present, filter options, and a behavioral caveat about naming. The gaps are pagination behavior for page/per_page and explicit semantics of default values (empty string and 0 meaning no filter). Given the complexity of the tool, the description is close to complete but not exhaustive.

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%, so the description carries the full burden—and it largely succeeds. Six of eight parameters get meaningful semantics with concrete examples: facility slug (dooly-state-prison), actor_category with the full enum, item_category with examples, arrest_made with a yes|no|unstated enum, year, and q as text match. Only page and per_page are left to inference, and their meaning is self-evident; default-value semantics (e.g., year=0 meaning 'all years') are not spelled out.

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: retrieving incident-level rows from GDC's published contraband arrest reports. It adds precise scope (2016-present, ~960 incidents, one row per incident) and enumerates the fields carried, making the tool's purpose unambiguous and distinguishable from an aggregate or stats tool.

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 clearly conveys what the tool returns (incident-level detail with filters) and thus implies when it applies, but it never explicitly says when to prefer it over alternatives. In particular, the sibling get_contraband_summary is a natural candidate for aggregate queries, yet no routing guidance is provided. Filters are listed, so an agent can infer usage, but exclusions and alternatives are left unstated.

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, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by explaining that counts are based on GDC's published reports rather than GDC's running tally, and why that choice was made. This goes beyond what annotations provide.

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 compact and front-loaded: the first clause states what the tool returns, and the rest adds high-value grouping, filtering, and data-source caveats. There is no filler or redundant restating of the title.

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

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

For a read-only summary tool with three optional parameters and no output schema, the description covers the main elements an agent needs: source data, grouping options, filters, and a data-quality caveat. It stops short of specifying the exact output shape or allowed category values, but the annotations cover safety and the overall complexity is modest.

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%, so the description carries the burden for parameter meaning. It compensates well by enumerating valid `by` values and clarifying that facility/year are optional filters, while noting they do not apply to `stats`. However, it does not enumerate valid values for actor-category, role, or item-category, nor explain defaults like year=0, so it is not fully complete.

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

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

The description clearly identifies the tool as producing summaries of GDC contraband arrest reports, with an explicit list of grouping keys (`by` = year | facility | actor-category | role | item-category | stats). This makes it easy to distinguish from siblings such as get_contraband_incidents, which presumably returns individual incidents rather than aggregated 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?

The description implies when to use the tool — when a summary/count of contraband arrests is needed — but it never names alternatives or explicitly says 'use get_contraband_incidents for raw incidents.' It does provide a usage constraint ('Optional facility slug / year filters (not for stats)'), but that is more parameter guidance than tool-selection 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 the tool read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds useful context by noting the data covers the latest published report year and specific demographic breakdowns, but it does not disclose details like data source, update cadence, or exact return structure.

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, tightly written sentence front-loads the core subject ('Admissions to Georgia prisons on drug offenses') and efficiently adds temporal scope and breakdown dimensions. There is no filler or repetition of the tool name or title.

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

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

For a zero-parameter report-retrieval tool with no output schema, the description supplies sufficient context: geographic scope, topic, time period, and breakdowns. It could be slightly more precise about what 'related measures' includes or how the latest year is identified, but the tool is simple enough that this is 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 has zero parameters, and the schema covers all of them by default, so the baseline is 4. The description adds value by indicating that the returned data is organized by sex, age band, and related measures, giving the agent a clearer idea of the fixed output dimensions.

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

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

The description clearly identifies a specific resource: admissions to Georgia prisons on drug offenses. It adds temporal scoping ('latest published report year') and output breakdowns ('sex, age band and related measures'), making the tool's purpose unambiguous and distinct from siblings like get_length_of_stay or get_population_snapshot.

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 usage context is implied: an agent can infer this tool is appropriate when drug-admission statistics for Georgia prisons are needed. However, it does not explicitly state when not to use it or mention any alternative tools, leaving the routing decision 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 mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral nuance via the conditional 'if GPS has one,' indicating the inspection data may not always be present. This goes beyond what annotations alone convey, though it could mention behavior for unknown slugs.

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 two sentences long with no wasted words. The core purpose is front-loaded, and the parameter guidance is concise and directly actionable. The example and cross-reference to list_facilities earn their 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 simple single-parameter read tool, the description covers what is returned (full public record and most recent inspection), the parameter semantics, and how to discover the parameter value. With annotations covering safety and idempotency, there are no major gaps for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only defines 'slug' as a string with no description. The tool description compensates fully by explaining that slug is the facility's gps.press slug, giving a concrete example ('macon-state-prison'), and directing users to list_facilities to find valid values. This is exactly the kind of semantic enrichment the schema lacks.

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

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

The description clearly states a specific verb ('Get') and resource ('one facility's full public record plus its most recent state health inspection'). It distinguishes itself from sibling tools like get_facility_staff_roster or get_population_snapshot by focusing on the full record plus inspection, not a specialized subset.

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

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

The description provides concrete usage context: fetch a single facility's comprehensive record and its latest inspection. It also advises using list_facilities to find the slug, which is helpful. It does not explicitly enumerate when not to use the tool versus each sibling, but the scope is clear enough for selection.

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 signal a safe, read-only, idempotent operation, and the description adds substantial behavioral context: the roster is a point-in-time observation, zero values are meaningful findings rather than missing data, and the medical-staffing interpretation should not be asserted as fact. No contradiction with the readOnly/idempotent 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?

The description is long but every sentence earns its place: front-loaded purpose, concrete examples, useful abbreviation guidance, and critical interpretation caveats. It is well structured and contains no filler or repetition.

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

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

Despite having no output schema and minimal input schema, the description gives the agent enough to invoke the tool correctly and interpret results: what the data source is, what questions it answers, how to find the slug, how titles are abbreviated, and how to handle dates and zero counts. The only slight gap is the limit parameter behavior, but the overall context is complete for correct use.

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 0% schema description coverage, the description compensates well by explaining slug with an example and clarifying title-filter behavior including GDC abbreviations. It omits any explanation of the limit parameter, though limit is optional and has a default, so this is a minor rather than critical gap.

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

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

The description clearly states the tool returns a staff headcount and list for one GDC facility from a GDC-produced roster, and gives concrete example questions it answers. It distinguishes itself from broader tools by emphasizing the single-facility scope and the roster source.

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 tells the agent to use list_facilities to find the slug, explains how the title filter works with abbreviations, and instructs the agent to always report the observed date. It also warns that the roster is a single-day observation, not a statement about current staffing, which is clear 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 mark this as read-only, idempotent, and non-destructive. The description adds meaningful context beyond that: it is roughly 2,000 words, contains editorial guidance, and includes claims GPS has publicly corrected and will not repeat. This clarifies expected behavior and content without contradicting 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?

The description is compact and front-loaded with the most important instruction, READ THIS FIRST. It efficiently lists the types of guidance contained in the file. The final metaphorical sentence earns its place by clarifying the tool's complementary role to the data tools.

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-only tool with no output schema, the description is complete enough. It tells the agent what the file is, why it matters, roughly how long it is, what guidance it contains, and where it fits relative to sibling data tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema fully covers parameter expectations and the description has no parameter burden. The baseline of 4 applies because there is nothing for the description to clarify.

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

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

The description clearly identifies the tool as retrieving GPS's orientation file for AI clients, specifically the llms.txt file, and states READ THIS FIRST. It distinguishes itself from sibling data tools by explaining it carries interpretative guidance rather than raw dataset numbers.

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 gives an explicit directive to use this tool first, and explains that it carries context the data tools cannot, such as which figures to lead with and which claims to avoid. The final paragraph reinforces the division of labor: datasets provide accurate numbers; this tool keeps the surrounding wording accurate.

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 establish read-only, idempotent, and non-destructive behavior, so the description need not repeat that. It adds genuine behavioral context by naming the public endpoint, describing the output metrics, and explaining that summary_only 'returns just the summary block.' This goes beyond the annotations without contradicting them.

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 carry the core purpose, result fields, and parameter behavior with no filler. The most important information is front-loaded, and each sentence 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?

There is no output schema, so the description's list of metrics is valuable, but it still omits key operating details such as what happens when offense/year are empty, what the trend summary contains, and how results are structured. For a simple read-only tool this is adequate but not 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?

Schema description coverage is 0%, so the description must compensate for the absence of parameter documentation. It explains summary_only's effect, but offense and year are merely said to be 'passed to the public endpoint'—no value formats, accepted offense names, or optionality/default behavior are given. With all three parameters optional, this leaves important ambiguity.

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 verb 'get' plus 'length of stay' identifies a concrete resource, and the description clarifies the actual content: average sentence, years served, percentage served, parole release share, and lifer figures. It does not explicitly name or contrast a sibling tool, but the offense/year scope and the phrase 'how long people actually serve' are specific enough to separate it from other get_* tools.

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

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

The description implies when to use the tool: when you need actual length-of-stay data for Georgia by offense and year. However, it gives no explicit guidance about when not to use it or which sibling tool would be a better fit, leaving selection largely to the agent's 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?

The description goes well beyond the annotations by explaining the no-argument return (whole document plus section list), how filters are matched against published lines, and why results are returned verbatim rather than re-tabulated. This adds meaningful behavioral context that the readOnly/idempotent hints do not cover.

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 densely informative with no wasted sentences: overview first, then behavior with no args, then each parameter with its unique effect. The line about verbatim matching justifies an otherwise surprising behavior, earning 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?

With no output schema, the description appropriately explains the return behavior (whole document, sections, verbatim filtered lines) and data coverage. It covers all incoming parameters and the no-argument case, leaving no major gaps for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully carries the burden of parameter documentation. It explains each of the three parameters ('section returns one section by name', 'year filters the yearly and monthly lines', 'facility_contains filters by-facility ranking AND returns cause-of-death breakdown') and gives concrete examples of valid section names.

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

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

The description clearly identifies the tool's verb and resource: 'Deaths in GDC custody since 2020' plus the data dimensions (yearly/monthly counts, cause-of-death breakdown, facility, facility type, security level, age). This precise scope distinguishes it from sibling tools that cover other domains like contraband, population, or parole.

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

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

The description provides strong guidance on how to use the tool, including the no-argument case, section selection, year filtering, and facility_contains behavior. It does not explicitly name alternatives or exclusion conditions, but the specific topic and param explanations make appropriate usage clear enough for an agent.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds 'from GPS's public mirror' to signal source/authority and 'full text' to signal scope, but doesn't describe error behavior or response format. No contradiction with 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?

Three short sentences total: the first states the tool's behavior, the second gives the key formatting rule, and the third provides examples. No filler, and the most important context 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?

For a single-parameter, read-only, idempotent getter, the description covers the essential context: what the tool returns, where the data originates, and how to format the citation. It stops just short of a perfect score because there is no output schema and no mention of edge cases such as missing or invalid sections.

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 description fully compensates by defining the `section` parameter as a bare citation without the 'O.C.G.A. §' prefix and giving three concrete examples. This is exactly the level of detail an agent needs to construct a valid call.

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?

Description opens with 'Full text of a section of the Official Code of Georgia Annotated', specifying a clear verb, resource, and scope. Unlike sibling tools focused on facilities, contraband, or mortality, this one targets a distinct legal-code resource, so an agent can distinguish it without extra inference.

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's no explicit when-to-use or alternative guidance, but the description clearly implies it is for retrieving full OCGA section text via GPS's mirror. It provides the citation format for the one parameter, though it doesn't state when to prefer this over search_site or get_page.

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 indicate read-only and idempotent behavior. The description adds valuable behavioral details beyond that: it fetches the .md twin, accepts URL/path/slug forms, truncates long pages, and supports offset/limit pagination.

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

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

The description is four focused sentences with the core purpose front-loaded. Every sentence adds value: accepted inputs, page coverage, truncation behavior, and a sensible pairing workflow.

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 simple read tool with no output schema, the description covers return format, accepted inputs, page scope, and pagination. An agent has enough context to select and call it correctly, including knowing to search before fetching.

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%, so the description carries the burden and it largely succeeds. It fully explains the path parameter's accepted input forms and explains how offset and limit are used for pagination, though it does not define bounds or special values.

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 the exact verb 'Read' and the resource 'gps.press page as clean Markdown', then enumerates the page types it covers. This clearly differentiates it from sibling tools that fetch specific datasets.

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 provides an explicit workflow: pair with search_site() to find a page, then read it here rather than guessing contents. It does not spell out when not to use this tool versus other sibling fetchers, 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 establish readOnly, idempotent, and non-destructive behavior. The description adds useful context about how the series was assembled and that metric definitions and an instruments note are included, but it does not describe the return format or any limitations. This is reasonable but not rich behavioral disclosure.

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

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

One sentence front-loads the core subject ('Georgia parole decisions by year') and then adds source and documentation context. No wasted words, and the structure is immediately understandable.

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 no-parameter, read-only tool, the description provides enough context to understand the data source and scope. It does not spell out the return shape, but the absence of an output schema and the simple nature of the tool make the description sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description has no parameter semantics to explain. The schema is empty and there is nothing further needed to invoke the tool correctly.

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 — Georgia parole decisions by year — and identifies the source series with provenance. This clearly distinguishes it from sibling tools like get_population_snapshot or get_system_statistics.

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 clearly indicates this is the tool for the GPS-assembled parole statistics series, providing enough context to know when to select it. It does not explicitly exclude alternatives, but none of the siblings target the same 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 read-only and non-destructive behavior. The description adds the weekly cadence, the scope of included bed types, and a critical semantic caution that components are parts of the total, not alternative totals. This adds value 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 short, focused sentences with no filler. The key resource is front-loaded and the semantic caveat is placed immediately after the component list, earning 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 zero-parameter read-only tool with rich annotations, the description sufficiently explains what data is returned and how to interpret the total. A slight gap is the lack of an explicit return shape for the jail backlog and facility-type components, but the description is still complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema coverage, so there is nothing for the description to explain. The baseline for zero-parameter tools is 4, and no parameter ambiguity exists.

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

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

The description uses a specific verb and resource ('Latest GDC population snapshot') and names the exact contents: total_in_gdc_custody, jail backlog, and facility-type components. It is clearly distinguishable from sibling tools focused on contraband, facilities, mortality, and other data.

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 establishes clear context by identifying the weekly 'Friday report' and latest snapshot, making it obvious when an agent needs current population custody data. It does not explicitly name alternatives or exclusions, but the semantic warning about the total being the only population figure provides useful guidance on interpretation.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds that the tool returns the published markdown of a specific analysis rather than a live or filtered query result, which is meaningful behavioral context beyond the annotations. It does not describe potential limitations, but the bar is lowered by the strong annotation set.

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 sentence with no filler. The core subject is front-loaded, and the output-format qualifier is placed at the end. Every phrase contributes useful 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?

For a zero-parameter, read-only tool returning a fixed published markdown, the description is complete. It states what data is covered and what form the result takes. No additional information is necessary for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the empty schema already documents this fully. The description correctly avoids inventing parameter details. The baseline of 4 for zero-parameter tools applies.

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

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

The description names a specific resource: Georgia's settlement payouts for prison death and injury claims, and explicitly identifies the output as the 'What Georgia Pays' published markdown. This makes the tool's purpose unambiguous and distinguishable from sibling data-retrieval tools like get_mortality_data.

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

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

The description implies the tool should be used when an agent needs Georgia settlement data for prison death and injury claims. However, it gives no explicit routing guidance or exclusions relative to sibling tools, so the selection decision is left mostly 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful transparency by stating that the output includes the update date and the data source that 'GPS assembled them from', giving the agent context about data provenance and freshness that the annotations do not provide.

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 sentence that front-loads the core purpose and uses a compact list for the data categories. It avoids redundant restatements of the tool name. The only minor issue is the slightly awkward phrasing 'GPS assembled them from', but it does not waste words.

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 the tool has no parameters, no output schema, and annotations that cover safety and idempotency, the description supplies the essential missing context: what data categories are included and that update date and data source are part of the result. This is sufficient for an agent to understand what the tool returns without over-explaining.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so there is no parameter ambiguity to resolve. The description compensates by outlining the returned content categories, which helps the agent understand what to expect even though the schema is empty.

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

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

The description states a specific resource ('Georgia prison system') and a clear verb ('get') tied to 'headline statistics', then enumerates the covered categories: population, mortality, demographics, facility counts, releases, and health measures. It is distinct enough from sibling tools like get_population_snapshot or get_mortality_data by framing itself as a system-wide aggregate, though it does not explicitly name those alternatives.

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 'headline statistics' implies this is the tool for a broad system-level overview, providing some usage context. However, it does not explicitly state when to use this tool versus more specialized sibling tools such as get_population_snapshot or get_mortality_data, so the agent must infer the intended selection.

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, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond annotations: filters are 'applied to the public list after it is fetched,' which discloses client-side filtering behavior rather than server-side querying. It also states the full set of returned fields, giving the agent a clear picture of output shape.

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 two sentences: the first delivers the core purpose and output fields; the second concisely lists filters and an example. There is no fluff, and the most actionable information is front-loaded. Every sentence 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?

With no output schema, the description compensates by enumerating the returned fields, which is sufficient for an agent to know what to expect. It also explains filter behavior and defaults (though defaults come from the schema). Missing pagination or ordering details are minor for a simple 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 0%, so the description carries the full burden for explaining parameters. It names all four parameters (facility_type, county, name_contains, active_only) and provides examples for facility_type ('State Prison', 'Transitional Center', 'County Prison'). It also clarifies the semantics of filtering as applied post-fetch. This substantially compensates for the empty schema, though it leaves some format details (e.g., exact county matching) implicit.

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 opens with a specific verb ('List') and a precise resource ('Georgia prison facilities'), and enumerates the exact fields returned (location, operator, security level, capacity, population, warden, food-safety score). It is clearly distinguishable from sibling tools like get_facility (single facility) and list_intelligence (intelligence entries).

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

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

The description implies its use case by describing the tool's listing behavior and available filters, but it does not explicitly state when to choose this tool over alternatives such as get_facility or when not to use it. The filter explanation gives context, but no direct exclusions or alternative routing.

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, idempotentHint, destructiveHint=false), so the bar is lower, but the description still adds substantial behavioral context: facility briefings come from a public index, issue briefings have no published index and may be incomplete, and the payload carries an `issues_note` flag. This completeness caveat meaningfully calibrates agent expectations. The incompleteness note slightly tempers openWorldHint=false, but the description is transparent about the limitation rather than contradictory, so no contradiction is flagged.

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

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

Four sentences, each with a distinct job: purpose, parameter semantics, read-onward routing, and completeness caveat. The purpose and filter semantics are front-loaded before the caveat, and every sentence earns its place with 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?

There is no output schema, so the description must convey return-shape expectations; it does mention the `issues_note` payload field and the incompleteness risk for issue briefings. It does not describe the structure of the returned list items (whether entries expose slugs, titles, dates) or pagination behavior, but for a two-optional-parameter list tool whose safety profile is fully annotated, those gaps are minor.

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%, so the description must carry the full burden for both parameters. It does so completely: `kind` filters to 'facility' or 'issue' (naming the allowed values) and `contains` filters on the slug. This fully compensates for the empty schema documentation.

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

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

The first sentence states a specific verb (list), a resource (GPS intelligence briefings), and scope (per-facility and per-issue analyses). It distinguishes itself from the sibling get_* tools, especially get_page, by framing itself as the enumeration step versus the read-in-full step.

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 explicitly names get_page as the alternative for reading a briefing and gives a concrete chaining example, get_page('intelligence/facility/dooly-state-prison'), which routes the agent from list to read. It lacks explicit when-not-to-use or exclusion conditions, e.g., 'if you already know the slug, call get_page directly,' so it falls just short of full routing guidance.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral details beyond the annotations: attribution_type accepts 'named' or 'anonymous', categories are discoverable via an empty call, and pagination starts at page 1 with per_page capped at 100. This is concrete and non-redundant.

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 compact and well-structured: scope first, then parameter semantics, then pagination. Every sentence adds useful information with no filler or repetition.

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 has no output schema and five parameters, and while category discovery and pagination are addressed, the 'search' parameter's behavior and the result format are left unspecified. Still, the description provides enough to make a safe first call and explore the collection.

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%, so the description must compensate for the schema's lack of parameter documentation. It explains attribution_type, category discovery, and page/per_page bounds, but it leaves the 'search' parameter semantically undefined—what it matches and how it behaves is not stated.

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?

Description states a specific verb and resource: 'Search GPS's published quote collection', and clarifies the content scope as statements from incarcerated people, families, officials and staff that GPS has already published. This clearly distinguishes it from sibling data-retrieval tools and search_site.

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 conveys the intended use case—searching already-published quotes—and gives helpful operational guidance such as calling with no arguments to discover categories. However, it does not explicitly contrast this tool with search_site or other siblings, so when-not-to-use is implied 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?

The description goes far beyond the annotations by disclosing that the tool parses the public /find/ results page because GPS publishes no JSON search API, that ranking reflects the site's own ordering, and that citations should be verified by following result URLs. This gives the agent important behavioral context not encoded in readOnlyHint, idempotentHint, or destructiveHint.

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. The first sentence front-loads the action, scope, and return type. The second sentence adds essential behavioral caveats about the scraping mechanism and citation workflow. Every clause 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?

The description covers the tool's purpose, source, output format, and a critical behavioral caveat (parsed HTML, no API). It lacks explicit explanation of the 'limit' parameter and does not mention error or edge-case behavior, but for a simple 2-parameter search tool with rich output and behavioral context, it is largely 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 0% schema description coverage, the description carries the burden for explaining parameters. It implies 'query' is the search term through the verb 'Search', but it never explains the 'limit' parameter, its default behavior, or any constraints. The parameter names are self-explanatory to a degree, but the description adds almost no explicit semantic value beyond the schema.

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

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

The description states a specific action ('Search'), a concrete resource ('gps.press'), the scope of content ('articles, data pages, research library topics and facility pages'), and the output ('ranked titles, URLs and summaries'). It clearly distinguishes itself from sibling tools like search_quotes by focusing on site-wide search rather than a dedicated quotes search.

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 gives clear context on when the tool is appropriate: when you need to search the public gps.press site across multiple content types. It also implies a caveat for using results (follow each result's URL before citing). It does not explicitly name alternative tools or state when not to use it, but the domain scope is implicit enough for an agent to route correctly.

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