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

With no annotations, description discloses that it returns a full record including allergies and schedule. While it implies read-only behavior, it could explicitly state no side effects, but the current description is sufficient for a fetch operation.

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 plus an example, no wasted words; front-loaded with key information (action and resource), making it efficient for AI parsing.

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 retrieval with one parameter and output schema present, the description covers purpose, usage, example, and return content completely, leaving no gaps.

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 has 0% coverage, but description adds meaning by showing example usage (child_id='kid-789') and expected return format, improving understanding beyond the schema's minimal title.

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 uses specific verb 'Fetch' and resource 'single child by id', lists included fields (allergies, schedule), distinguishing it from sibling tools like list_children (multiple) and other entity-specific 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?

Provides explicit example use cases ('what are the allergies for child X?', 'show me the enrollment record') and a concrete example with child_id='kid-789', clearly guiding when to use this tool.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It implies a read-only fetch without side effects, but does not mention error handling, permissions, or what happens if the ID is not found. This is adequate for a simple tool but lacks comprehensive transparency.

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

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

The description is very short, with two sentences front-loaded with the purpose. It contains no fluff or unnecessary detail. However, it could be slightly more concise by integrating the example into the first sentence, but current form is effective.

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's simplicity (one parameter), the description covers the main purpose and output fields. Since an output schema exists, return values are not needed. It could mention error scenarios or permissions, but it is largely complete for a single-fetch 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%, and the description does not explain the `classroom_id` parameter beyond mentioning 'by id'. The parameter is self-explanatory, but the description adds minimal value over the schema. It should at least specify the expected format or provide an example.

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 verb 'Fetch' and the resource 'single classroom by id', and lists specific fields (capacity, age range, lead teacher). This distinguishes it from sibling tools like `list_classrooms` (list all) and `get_child` (different entity).

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 a concrete usage example ('what's the capacity and age range for classroom 33?'), giving clear context for when to use the tool. It does not explicitly state when not to use or mention alternatives, but the example implies its appropriate scenario.

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?

No annotations provided, so description carries full burden. It discloses the returned fields (guardians, children, contacts, balance) but does not mention permissions, error handling, or rate limits. For a simple fetch, it is adequate but could be more thorough.

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 plus an example. The first sentence states purpose, the second provides usage context, and the example illustrates the parameter and return structure. No unnecessary 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 existence of an output schema (which covers return values), the description adds context by listing key fields and providing an example. It lacks info on error conditions or optional fields, but overall it is sufficient for a simple fetch 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?

With 0% schema description coverage, the description must add meaning. It mentions 'family_id' in the example but does not describe its format or constraints. The single parameter is simple, but lacking details on validation or type.

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 'Fetch a single family by id' and lists the included fields (guardians, children, contacts, balance). While it doesn't explicitly distinguish from sibling tools like get_child or list_families, the different resource names make the distinction clear.

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?

Description provides specific query examples ('what's the balance on family 555?') and shows a typical use case. It doesn't explicitly state when not to use or mention alternatives, but the guidance is sufficient for common scenarios.

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?

No annotations provided; the description does not disclose behavioral traits (e.g., read-only, error handling, required permissions) beyond the implied 'get' operation.

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, front-loaded sentences with no superfluous content, efficiently conveying purpose and usage.

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?

Covers the tool's purpose, usage, and returned fields; no need to describe output schema since it exists. Lacks error handling or edge cases, but adequate for a simple fetch.

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 parameter program_id has 0% schema description coverage; the description provides an example ('program 7777') but no format or further semantics, offering moderate compensation.

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 it fetches a single program by id and lists the returned fields (description, schedule, capacity, fee), distinguishing it from sibling list_programs.

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

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

Provides a concrete usage example ('what's the capacity and weekly fee for program 7777?') but does not explicitly mention when not to use or alternatives beyond the example.

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?

No annotations are provided, so the description carries the burden. It describes the fetch operation and gives an example return, but does not discuss error handling, permissions, or what happens if the school is not found. It is transparent about the basic behavior but lacks full 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?

The description is two sentences plus an example, all front-loaded and concise. Every sentence adds value 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?

Given the output schema exists (indicated in context signals), the description does not need to detail return values. The example return is sufficient. The description covers the main use case 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 coverage is 0%, so the description must add meaning. It clearly states the parameter 'school_id' is used to identify the school and provides an example with 'abc-123', which adds context beyond the schema's type and title.

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 starts with 'Fetch a single school by id' which is a specific verb and resource. It lists fields (name, address, phone, hours) and distinguishes from sibling tools like get_child or get_classroom by focusing on school 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 provides example query intents ('what's the address of school 1234?') and includes a concrete example. It does not explicitly state when not to use, but the examples give clear usage context.

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?

No annotations are provided, so the description carries the full burden. It describes a read operation but does not disclose any behavioral aspects such as idempotency, required permissions, or what happens if the staff member doesn't exist.

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?

Extremely concise: one sentence for purpose, one for usage example. No filler. Front-loaded with the action and key fields.

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

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

Given the presence of an output schema (so return format is handled elsewhere) and a single required parameter, the description is nearly complete. It lacks error-case behavior but covers the primary usage well.

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 adds no further meaning to the single parameter 'staff_id' beyond what's in the schema. It only mentions 'by id', which is inherent from the parameter name.

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 'Fetch a single staff member by id' and lists the fields returned (name, role, classrooms, schedule). This distinguishes it from sibling tools like list_staff which would return multiple staff members.

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 use case example: "what's the role and classroom assignment for staff 222?" This gives clear context for when to use it. However, it does not mention when not to use it or alternatives like list_staff.

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

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

With no annotations, the description fully discloses behavior: it is a read operation ('calls list_schools'), acts as a smoke test, and describes the error type and resolution. No contradictions.

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 extremely concise: two sentences plus an example call. It front-loads the core purpose, then adds troubleshooting context. Every sentence adds value with no redundancy.

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

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

For a zero-parameter health check tool, the description is complete. It explains purpose, failure behavior, and provides an example. Since the output schema exists (context signal), the agent can understand the return format without further explanation.

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, and the input schema confirms this (0 properties). The description adds nothing about parameters because none exist. Baseline 4 is appropriate as no additional parameter semantics are needed.

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's purpose: 'Verify credentials work' and specifies that it does so by calling 'list_schools (the cheapest read)'. This specificity distinguishes it from sibling tools that retrieve 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 provides troubleshooting steps for a common error (ProcareAuthError) and configuration tips. While it doesn't explicitly exclude alternatives, the context makes it clear this is a first-step smoke test. Additional guidance on when to use vs other tools would elevate it to a 5.

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

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

No annotations provided. Description explains filtering behavior and parameter meanings but omits default ordering, pagination, or result format.

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?

Concise intro, two usage examples, and parameter list. No wasted words, front-loaded with purpose.

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?

Covers parameters and usage examples. Output schema exists, so return format is not required. Missing details on sorting or pagination, but sufficient for a filtering list 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 has 0% description coverage, so description compensates with clear explanations for all 5 parameters (e.g., 'restrict to one school', 'ISO date inclusive'). Adequate but lacks format examples.

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 clearly states 'List attendance records' and mentions filters. Use cases help differentiate from other list tools, but no explicit sibling distinction.

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

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

Explicit examples show when to use (e.g., 'who was absent on Monday at school 1234?'). No exclusions or alternatives mentioned, but 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?

No annotations are provided, so the description bears the full burden. It discloses pagination behavior (offset) and a server-side cap on limit, and shows an example output. It lacks mention of read-only nature, authentication, or error handling, but for a list tool this is adequate.

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 concise and well-structured: purpose, usage guidance, parameter descriptions, and an example. Every sentence adds value with no redundancy.

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

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

Given the presence of an output schema, the description covers the tool's purpose, usage, parameters, and pagination behavior. The example output compensates for missing schema details. No critical gaps remain.

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 coverage is 0%, but the description explains all three parameters in detail: school_id for restriction, limit with a server cap, offset for pagination. The example demonstrates usage and output format, adding significant 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 clearly states the tool's verb ('List') and resource ('children enrolled'), with an example that distinguishes it from sibling list tools (e.g., list_classrooms) by specifying the resource type. The usage examples confirm it is for listing children.

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 says 'Use when' with two example queries, covering filtered and unfiltered cases, and mentions pagination with offset. However, it does not provide 'when not to use' or explicitly name alternatives like get_child.

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?

No annotations provided, so description bears full responsibility for behavioral disclosure. Only mentions optional filtering; lacks details on return format, error handling, or restrictions (e.g., what happens when school_id is invalid). Output schema exists but description does not reference it.

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?

Very concise—two sentences front-loaded with purpose and usage example. No extraneous 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?

For a simple list tool with one optional parameter and an output schema, the description is minimally viable. However, it lacks any mention of output format, error scenarios, or behavioral traits, which would be important given no annotations.

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%. Description adds minimal semantic value by explaining school_id is for filtering, but does not provide format, constraints, or behavior differences for null vs. non-null 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?

Description clearly states verb (List), resource (classrooms), and scope (optionally filtered by school). Distinct from sibling list tools like list_children and list_families by specifying filtering capability.

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?

Includes a 'Use when' section with an example query, providing clear usage context. Does not explicitly state when not to use or list alternatives, but the context is sufficient for this simple tool.

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

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

No annotations provided, so description carries full burden. It covers filtering and pagination but does not disclose authorization needs, rate limits, or behavior for empty results. Acceptable for a list operation.

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?

Description is brief and front-loaded with purpose. Includes usage examples and parameter details. No superfluous text.

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?

Output schema exists, parameters are documented, and use cases are given. Lacks details on default limit or error handling, but sufficient for a list tool with three optional parameters.

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 has 0% description coverage, but description adds meaningful explanations: school_id restricts to one school, limit for max records, offset for pagination. This compensates well for the schema gaps.

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 'List families (households), optionally filtered by school.' It uses a specific verb and resource, and distinguishes from sibling tools like get_child or list_classrooms.

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

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

Provides example use cases ('show me all families at school 1234' and 'how many active households?'), and indicates optional filtering. Does not explicitly exclude alternative tools, but context is sufficient.

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?

No annotations provided, so description carries full burden. It describes listing with filtering but lacks details on default behavior (e.g., default limit, sorting, pagination) and whether it includes only paid or all invoices.

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?

Very concise: one-line purpose, example queries, then bullet-like args. Every sentence adds value; no waste.

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

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

Output schema exists, so return values need no explanation. Covers main purpose and parameter semantics. Could mention default limit or ordering for completeness.

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 description adds meaning by listing each parameter with its purpose and date format (ISO). Could be more precise about ID formats or default 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 clearly states 'List payments / invoices, filterable by family / school / date range', which is specific and distinguishes from sibling tools like get_child or list_families.

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

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

Provides explicit use cases (e.g., 'show me all payments for family 555 in October') and explains when to use filters. However, it does not explicitly state when not to use this tool compared to alternatives.

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?

No annotations are provided, so the description carries full burden. It only mentions listing and filtering, but omits behavioral traits such as read-only nature, pagination, limits, or whether it returns all programs matching criteria. This is insufficient for a list tool.

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

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

The description is extremely concise, using two sentences for purpose and usage, then a clear args list. Every word adds value, no repetition or filler.

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

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

Given the tool's simplicity and existence of an output schema, the description covers purpose, usage, and parameter meaning adequately. Missing details like default behavior (returns all programs) are implied but not explicit; still sufficient for a straightforward list 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?

With 0% schema coverage, the description adds basic semantics: 'school_id: restrict to one school' and 'active: filter by active flag (True / False / None = all).' It clarifies the default for active but does not elaborate on the meaning of 'active' in context or other aspects like format.

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 'List programs (camps, preschool, after-school, summer)', using a specific verb and resource. It distinguishes from sibling tools like 'get_program' (single vs. list) and other list tools by specifying program types.

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 explicit 'Use when' examples covering common queries like 'what programs do we currently offer?' and 'show me the active summer programs at school 1234.' It does not explicitly mention when not to use or alternatives, 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?

No annotations are provided, so the description must reveal behavior. It indicates a read operation (list) but doesn't explicitly say it's non-destructive or clarify pagination, sorting, or required permissions. The mention of a 'limit' parameter hints at pagination, but additional details (e.g., returns a list of registration objects) would improve transparency. The presence of an output schema partly compensates.

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 very concise: a single-line title, three example use cases, and a bullet list of arguments. It is front-loaded with the core purpose, and every sentence adds value. No superfluous text.

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 presence of an output schema (return format documented) and 4 simple parameters, the description covers the essential functionality and use cases. It lacks details like default limit, filtering logic (AND vs OR), and ordering, but for a straightforward list tool, it is sufficiently complete.

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

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

The input schema has 4 parameters with 0% description coverage, so the description must add meaning. It provides brief explanations for each parameter (e.g., 'program_id: restrict to one program.'), which clarifies their purpose beyond the schema. However, the descriptions are terse and could be more detailed.

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 explicitly states 'List registrations (enrollments)' with a clear verb and resource. It mentions filtering by program/child/school, which distinguishes it from sibling tools that list other entities (e.g., list_children, list_programs). The purpose is unambiguous.

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

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

The description provides concrete example questions like 'who's enrolled in program 7777?' or 'what programs is child X currently in?', guiding the agent on when to use. It doesn't explicitly state when not to use, but the examples cover common use cases clearly.

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?

No annotations provided, so description carries full burden. It discloses the operation (listing all accessible schools) and gives an example return format. Lacks details on auth or pagination, but sufficient for a read-only list tool.

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

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

Three sentences with no waste. Includes a usage hint and example output. Perfectly concise.

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?

Covers purpose, usage context, and output format. Lacks details on error scenarios or output field descriptions, but output schema exists separately. Adequate for a simple list 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?

No parameters in schema, coverage 100%. Description adds no param info, which is appropriate since none exist. Baseline 4 for 0-param tools.

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 'List all schools/locations accessible to the enterprise account,' using a specific verb and resource. It distinguishes from sibling tools like get_school and list_children by focusing on schools and providing usage context.

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

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

Explicitly tells when to use this tool (e.g., 'what schools are on our Procare account?') and recommends using it before per-school tools. Provides example questions and implies alternatives.

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?

No annotations are provided, so the description carries full burden. It only mentions optional filtering but does not disclose behavioral traits such as authentication requirements, rate limits, pagination, or what happens when no results are found.

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 extremely concise with two sentences and an example line. Every part is necessary and front-loaded. No wasted 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 low schema coverage and no annotations, the description is minimal. It covers the basic purpose and filtering but lacks behavioral details. However, the presence of an output schema reduces the need to explain return values.

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. It adds that the parameters are for filtering by school and active flag, which provides basic meaning beyond the schema's type definitions. However, it lacks details on value formats or constraints.

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 verb 'list' and the resource 'staff members', and specifies optional filters by school and active flag. This distinguishes it from sibling tools like 'get_staff_member' (single record) and other list 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?

Provides concrete examples of when to use the tool (e.g., 'who are the active teachers at school 1234?'). Does not explicitly mention when not to use it or alternatives, but the examples are clear enough for most cases.

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