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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond the schema by specifying that records are returned as a single JSON or CSV payload and that nested fields are flattened in CSV. This helps the agent predict output shape and format-specific behavior.

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

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

The description is three sentences with no filler. It front-loads the core purpose, immediately gives the usage context, and ends with a necessary format behavior. 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?

Given the rich input schema, output schema presence, and annotations, the description is complete enough for correct selection and invocation. It covers when to use the tool property, the output format, and the CSV-specific behavior, while parameter details are already fully documented.

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?

All four parameters are fully described in the input schema, so the schema carries the baseline burden. The description adds extra meaning around the format parameter by clarifying that the result is a single payload and by describing CSV flattening of nested fields. This is modest but meaningful 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 action: 'Generates a batch of synthetic person records as a single JSON or CSV payload.' It identifies the resource (synthetic person records), the verb (generates), and the output format, making the tool's purpose unambiguous. It also hints at the distinction from single-record generators by framing this as a bulk alternative.

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 tells the agent when to use this tool: 'Use this instead of repeated single-record calls when producing a dataset or fixture file.' This provides clear context and an implicit exclusion, though it does not name specific sibling tools or state when not to use it beyond the repeated-call 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the output is synthetic and Nigerian, and that region influences placement. It does not explain randomness, output format, or behavior when region is omitted, but the simplicity of the tool and annotation coverage keep this at a solid 3.

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 concise sentences with no filler. The first sentence front-loads the core purpose, and the second provides the only parameter guidance. Every word earns its place.

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

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

For a simple read-only generator with one optional parameter and an output schema, the description covers what it does and how to influence output. It could mention the optionality of region or typical address components, but the output schema supplies return details and annotations cover safety, so the gap is 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 compensate. It clarifies that 'region' refers to a geographic part of Nigeria, giving meaning to the enum values. However, it does not state what happens when the optional region is omitted (e.g., random choice), which is a minor 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 states a specific verb ('generates') and resource ('synthetic Nigerian address'), which clearly differentiates it from sibling tools like generate_states and generate_lgas that produce related but distinct geographic entities. The 'Nigerian' qualifier further narrows scope, leaving no ambiguity about what the tool produces.

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 guidance for the region parameter (use it to place the address in a part of the country), which is helpful. However, it does not explicitly contrast with alternatives like generate_states or generate_lgas, nor does it state when to prefer this tool over those. Usage is implied but not made explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description usefully adds that the bank account is synthetic and intended for test data, but it does not add deeper behavioral context such as randomness, determinism, or output characteristics.

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, front-loading the action and the resource. Every word earns its place.

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

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

For a simple tool with no required parameters, a read-only annotation, and an output schema, the core invocation is adequately covered. However, the optional 'bankName' parameter is undocumented and the description provides no sibling-selection guidance, leaving minor but real 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 description coverage is 0%, so the description must compensate by explaining the 'bankName' parameter, but it never mentions it. The parameter name is somewhat self-explanatory, yet optionality, expected format, and behavior when omitted are left to inference.

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

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

The description names a specific verb ('Generates'), a concrete resource ('a synthetic bank account'), and the intended context ('for test data'). This clearly differentiates it from sibling generators such as generate_person, generate_vehicle_record, and generate_company.

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

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

The phrase 'for test data' implies when the tool is appropriate, but there is no explicit guidance about when not to use it or which sibling alternative to choose. With 27 sibling generators, the agent must largely infer selection from the tool name.

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 and destructiveHint=false, covering safety. The description adds the meaningful context that the result is synthetic, which is important for agents to understand they are not getting real-world data.

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

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

The description is a single, concise sentence that immediately communicates the tool's function. It contains no filler or redundant wording.

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 parameterless, read-only synthetic generator with an output schema and safety annotations, the description is complete. Nothing else is required for an agent to select and invoke the tool 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, so there is no parameter burden for the description to carry. A baseline of 4 is appropriate because no additional parameter explanation is 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 verb ('generates') and the resource ('synthetic blood group'), so an agent knows exactly what this tool produces. It is distinct from sibling generators by naming a unique resource, though it does not explicitly call out how it differs from similar generator 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?

There is no guidance about when to use this tool versus alternatives such as generate_person or generate_genotype. The tool is a simple generator, but the description does not mention context, prerequisites, or exclusions.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds meaningful behavioral context by stating the output is synthetic and intended for test data only, ruling out any expectation of a real BVN lookup.

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

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

A single, front-loaded sentence delivers the key facts without redundancy. Every word adds value.

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 parameterless generator with an output schema already present, the description is fully sufficient. It tells the agent what is generated and the allowed use, and no invocation details are missing.

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

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

There are zero parameters and schema coverage is 100%, so the description does not need to explain any parameter details. The baseline of 4 applies because there is nothing missing for an agent to invoke the tool.

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

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

The description names the exact action ('generates'), the specific artifact ('synthetic BVN'), and the scope ('test data only'). This clearly separates it from sibling generators such as generate_nin or generate_person.

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?

'For test data only' is an explicit usage context that tells an agent when this generator is appropriate. It does not explicitly enumerate sibling alternatives or when-not-to-use cases, but the boundary is clear enough for a parameterless generator.

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, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds the critical 'synthetic' qualifier (indicating fake data) and the geographical scope 'Nigerian', which are not in the annotations. This aligns with the annotations and adds valuable context about the nature of the output.

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 is fully front-loaded with the action and the output type. There is no filler or redundancy; every word 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?

Given the simplicity (0 parameters), the existence of an output schema (which documents the return structure), and annotations covering safety, the description is complete for an agent to understand what the tool does and when to invoke it. No additional behavioral or contextual details are needed.

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 obligation to explain them. The baseline for 0 params is 4, and since the description doesn't attempt to add parameter details (which would be unnecessary), it meets the baseline appropriately.

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 'Generates a synthetic Nigerian company record' uses a specific verb (generates) and resource (company record), and includes the qualifier 'Nigerian' which distinguishes it from other generators. Among siblings like generate_person, generate_vehicle_record, etc., it clearly identifies the unique output type.

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 clear context: this tool generates a synthetic Nigerian company record. While it doesn't explicitly state when not to use it or name alternatives, the purpose is unambiguous and the sibling list makes the domain obvious. There is no misleading information, so it meets the 'clear context, no exclusions' criterion.

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 readOnlyHint and destructiveHint already provided by annotations, the description adds meaningful context: output is an array, default is 10 records, count is optional, and fields are geographically coherent. This exceeds what annotations alone communicate, though it does not detail randomness or reproducibility beyond the schema.

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

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

Two sentences, front-loaded with the core purpose and followed by the default-count behavior. There is no filler or repetition of schema details.

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 an output schema exists, a 100%-covered input schema, and safety annotations, the description is adequate for correct invocation. It lacks an explicit mention of seed reproducibility, but that is already in the schema, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents seed, count, gender, and language. The description adds only the default count behavior ('returns 10 records'), which is minor. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 ('Generates') and resource ('an array of synthetic people') with a clear qualifier ('geographically coherent identity, address, state, and LGA fields'). This distinguishes it from sibling tools like generate_people (generic) and generate_consistent_person (singular rather than array).

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: use this tool when multiple synthetic people with geographically coherent fields are needed, and it notes the default count behavior. It does not explicitly name alternatives or exclusions relative to siblings, so it stops short of 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?

Annotations already mark the tool read-only and non-destructive, lowering the bar. The description adds useful behavior: the title is filtered to the ethnic group, and the returned record includes the language and source region. It does not enumerate every generation rule, but the added facts are meaningful 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?

Three concise sentences with the core behavior front-loaded, followed by the distinctive title-filtering behavior and then the return/params. There is no filler or unnecessary repetition of schema details.

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 an output schema to describe return values, annotations to cover safety, and all three parameters documented in the schema. The description adds the one thing the schema cannot express: what makes the person 'consistent' and how the title relates to ethnicity. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description's phrase 'title is filtered to match the ethnic group' connects language to the title logic and adds a little meaning, but it does not explain seed behavior beyond the schema or add new detail for gender. The optionality of language and gender is already present in 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 opens with a specific verb and resource: 'Generates one synthetic person whose identity, address, state, and LGA are geographically coherent.' It also adds the distinguishing behavioral detail that the title is filtered to match the ethnic group, separating it from generic generate_person or generate_title. It clearly states the extra return value: 'Also returns the language and region the record was drawn from.'

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 that this tool should be used when a single person record with geographically coherent fields and an ethnically matched title is needed. It does not explicitly name alternatives or say when not to use it, but the unique coherence property makes the intended use case apparent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context: 'synthetic' indicates non-real data, and 'and age' shows that age is also generated. It does not explain randomness, how age is calculated relative to the current date, or how min/max age constraints affect the result.

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 one short, front-loaded sentence with every word earning its place. It avoids repeating the schema or annotations and wastes no space. This is an appropriate size for a tool with only two optional parameters and an output schema.

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

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

The tool is simple, and the output schema plus annotations cover return structure and safety, so the description need not explain those. However, with zero schema descriptions and no usage guidance, the semantics of minAge/maxAge and the decision among sibling tools remain unresolved. It is minimally usable but not 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 bears the burden of explaining minAge and maxAge, but it does not mention them at all. An agent must infer from property names that these parameters bound the generated age. No defaults, inclusiveness, or behavior for invalid combinations are provided.

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 ('Generates') and names a concrete resource ('synthetic date of birth and age'), which clearly distinguishes it from sibling tools like generate_name or generate_phone_number. It is not a pure tautology because it adds 'synthetic' and the fact that age is also produced. It does not, however, clarify how it relates to generate_person, which might also produce a date of birth.

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

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

There is no guidance about when to use this tool versus the many sibling tools. It does not mention alternatives such as generate_person or generate_detailed_person for full profiles, nor does it state when a standalone date of birth is appropriate. The agent is left to infer selection from the tool name alone.

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

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

Annotations already cover readOnlyHint=true and destructiveHint=false, lowering the bar. The description still adds real behavioral value by disclosing that output is an array, default count is 1, default age range is 22-65, and records bundle many data categories. No hidden mutation or side effects are left undisclosed.

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

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

Three tight sentences: first gives verb and resource, second enumerates record contents, third gives defaults and how to change them. Every sentence carries useful information and the key facts are 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 generation tool with six optional parameters, an output schema, and readOnly annotations, the description covers purpose, contents, defaults, and age-range adjustment. It doesn't need to explain return values because an output schema exists; the only minor omission is not mentioning seed reproducibility, but the schema already handles that.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by revealing the default count and default age range and by explaining that minAge/maxAge widen the range. Seed, gender, and language are adequately described in the schema, so no further compensation is 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 names a specific verb ('generates') and resource ('array of synthetic detailed people'), and enumerates the record contents (identity, health, financial, kin, education, work, vehicle). This clearly distinguishes it from siblings like generate_person or generate_people by the 'detailed' and multi-record scope.

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 states defaults (one record, ages 22-65) and how to widen the age range, giving clear context for typical use. However, it never names sibling tools or specifies when to choose this over generate_people, generate_detailed_person, or generate_consistent_people; selection must be inferred from the name and content detail.

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

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

The description adds valuable behavioral context beyond the annotations: it explains that all fields are derived from one identity, ensuring internal consistency (graduation follows birth, employment follows graduation), and discloses the age-range default and the edge case where education is null. This goes beyond the readOnlyHint and destructiveHint annotations, which only cover safety. However, it does not mention seed reproducibility or output format, though those are covered by the schema.

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

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

The description is two sentences, front-loaded with the core purpose and scope, then adding the age/education nuance. There is no fluff or redundancy; every sentence earns its place. It is concise yet informative.

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 essential aspects: what the tool does, the consistency guarantee, and the age/education behavior. The output schema handles the return structure, and annotations handle safety. The only notable gap is the lack of explicit differentiation from sibling tools, which is partially covered by the name and content. Overall, it is complete for an agent to invoke it correctly, with minor room for improvement in routing guidance.

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

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

Schema description coverage is 100%, so all five parameters are documented in the schema itself. The description adds extra meaning by explaining the effect of minAge and maxAge (default 22-65) and the condition under which education is null, which is not present in the schema. This enriches parameter understanding beyond the schema's field-level descriptions.

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 'Generates' and the resource 'one synthetic detailed person', and enumerates the domains covered (health, financial, kin, education, work, vehicle). It distinguishes itself from simpler siblings like generate_person by emphasizing 'detailed' and 'geographically consistent', which is a unique feature not present in other generators.

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 some usage context (default age range, how to widen it, and the education-null edge case) but does not explicitly state when to choose this tool over alternatives such as generate_person or generate_consistent_person. It implies usage through the 'detailed' descriptor but lacks explicit exclusion or alternative guidance, leaving the selection partially 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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses meaningful behavior: the degree is chosen to fit the person's age, the course matches the degree's discipline, and null is returned when the age is too young. This gives the agent a precise mental model of the tool's internal logic and edge case.

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, each earning its place: the first defines the operation, the second explains generation logic, the third handles the edge case. The core action is front-loaded and there is no filler.

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

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

With an output schema present, return values need no explanation, and the description capably covers purpose, age logic, and null behavior. The only meaningful gap is the undocumented language parameter, which could affect the generated record's content. Overall, the definition is nearly complete 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 50%: the age parameter has a schema description, and the description adds valuable age semantics (determines valid degree). However, the language parameter (hausa/igbo/yoruba) is completely undocumented in both schema and tool description, leaving its effect on the record unknown. The description compensates for age but not for the other parameter.

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 and resource: 'Generates a synthetic education record.' It then adds unique behavior (age-based degree feasibility, course matching degree discipline) that distinguishes it from sibling generators like generate_university or generate_work_record. The purpose is unmistakable.

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 clear context for use: 'Pass an age' and explains what the tool does with it, including the null-return condition. It does not explicitly mention alternatives or when-not-to-use, but the usage context is unambiguous enough for an agent to apply it correctly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the word 'synthetic' but provides no additional behavioral details (e.g., randomness, format, or how it interacts with the name parameter). It is consistent with annotations but adds minimal context.

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

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

The description is a single, direct sentence with no filler. It front-loads the purpose and wastes no words, achieving ideal conciseness for a simple tool.

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 low complexity and the presence of an output schema, the description is mostly sufficient for calling the tool, but the missing parameter semantics and lack of usage context leave it incomplete. It is adequate for a trivial generator but not fully self-contained.

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 explain the optional 'name' parameter, but it does not mention it at all. An agent cannot know what the name does or how to use it, leaving a critical gap for a parameter that could affect generation.

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 ('generates') and resource ('synthetic email address'), clearly distinguishing it from siblings like generate_person or generate_name. The title reinforces this, and the wording is not a tautology.

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?

No guidance is given about when to use this tool vs alternatives. The description does not mention any criteria, conditions, or exclusions, nor does it reference sibling tools. The agent is left to infer usage solely from the name, which is insufficient.

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

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

The description adds 'synthetic', which clarifies that the output is simulated and not real, a useful behavior beyond the annotations' read-only/non-destructive hints. However, it doesn't describe what calling the tool implies (e.g., no side effects, deterministic vs random), though the lack of parameters and presence of output schema reduce the gap.

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

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

The description is a single sentence with no wasted words. It front-loads the action and object, and there is no filler or redundancy. Exactly as concise as needed for a parameterless generator.

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 tool with no parameters and an output schema, the description is largely sufficient. The agent knows it generates a synthetic genotype and can rely on the output schema for return structure. The only gap is usage context among siblings, but that is already penalized in usage_guidelines.

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 add. According to the rubric, a zero-parameter tool gets a baseline of 4, and the description is consistent with that. It doesn't interfere with the empty 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 clear verb 'Generates' and a specific resource 'synthetic genotype', so an agent can tell it produces a genotype. It does not explicitly differentiate from siblings, but the resource name is unique among the generate_* tools, so it's identifiable without deeper schema inspection.

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?

No guidance is given on when to use this tool versus any sibling. With 27 generate_* siblings, an agent gets no hints about selecting this over alternatives like generate_person or generate_blood_group. No exclusions or conditions are provided.

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, lowering the burden. The description adds that the tool returns the available LGAs rather than generating a random one, but it does not explain list shape, ordering, or relationship to states. With strong annotations, this is adequate but not rich.

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

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

One short sentence wastes no words and front-loads the core message. It is appropriately sized for a zero-parameter read-only lookup.

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

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

For a zero-parameter tool with an output schema and read-only annotations, the description is complete: an agent knows the operation is a safe list lookup. Nothing else is needed 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?

There are zero parameters, so the semantics are vacuous and the description need not elaborate. The baseline for a no-parameter tool is 4.

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

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

The description states a specific verb ('Returns') and resource ('available Nigerian LGAs'), making the core function clear. It distinguishes the resource from sibling generators like generate_states and generate_address, though it does not explicitly contrast with them.

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?

No usage guidance is given: the description does not say when to choose this tool versus generate_states or generate_address, nor does it mention prerequisites or exclusions. The agent must infer from the name that this is the LGA-listing 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?

Annotations already establish readOnly and non-destructive behavior. The description adds the useful context that the output is synthetic and Nigerian-specific, but it does not disclose plate format, randomness, or any generation constraints beyond that.

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

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

The description is a single compact sentence that is front-loaded and contains no filler. Every word contributes to the meaning without unnecessary elaboration.

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 output schema and annotations cover some context, but the description leaves the state parameter entirely unexplained, including whether it is a Nigerian state name, abbreviation, or something else. This gap prevents an agent from confidently invoking the tool with a correct state value.

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 includes a single 'state' parameter with 0% description coverage, and the tool description does not mention state at all. There is no guidance on allowed values, default behavior, or how state affects the generated plate, so the description adds no parameter meaning.

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 ('Generates'), a concrete resource ('Nigerian license plate'), and the synthetic nature of the data. It is clear, though it does not explicitly differentiate itself from related sibling generators such as generate_vehicle_record.

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 no guidance about when to choose this tool over alternatives like generate_vehicle_record or other data generators. Intended usage is only implied by the tool name and resource, not explicitly stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the result is synthetic and age-dependent, implying a constrained random generation.

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

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

Two sentences with no filler; the core action and the key usage nuance are 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?

For a simple generator with an output schema present, the description covers the main invocation concern (age filtering). A minor gap is that it does not explicitly state what happens when age is omitted, even though the parameter is optional.

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 compensate for the age parameter's meaning. It explains that age is used to rule out implausible statuses, giving semantic value beyond the schema's bare integer range. It does not fully spell out edge cases or default behavior when age is omitted, but the intent is clear.

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

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

States a specific verb ('Generates') and resource ('synthetic marital status'), which clearly identifies the tool's function among many generate_* siblings. The second sentence adds the age-based filtering behavior, further distinguishing it from sibling generators.

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 clear context: pass an age to rule out implausible statuses, which implicitly tells the agent how to use the tool effectively. It does not explicitly name alternatives or exclusions, but the sibling set is large and homogeneous, so this level of guidance is reasonable.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds 'synthetic', indicating the name is fake, but it does not disclose whether the generated name is random, independent across calls, or consistent—an important distinction given the generate_consistent_person siblings.

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 fluff, front-loading the verb. It is appropriately short, though it is concise to the point of under-specification because it omits behavioral and parameter context.

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 large sibling family including generate_person, generate_consistent_person, and generate_title, the description is not complete enough for an agent to reliably choose this tool. The output schema may cover return shape, but the description does not provide the behavioral or routing context needed to fully disambiguate it.

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 never mentions the gender or language parameters. The 'Nigerian' qualifier hints that the language enum values correspond to Nigerian languages, but the agent must infer all parameter meaning from the enum labels alone. No defaults, optionality, or combination behavior are described.

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, 'Generates', and a specific resource, 'synthetic Nigerian name', which clearly distinguishes it from sibling tools like generate_person, generate_people, and generate_title. The 'Nigerian' qualifier narrows the scope further and makes the tool's purpose immediately recognizable.

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

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

There is no guidance on when to use this tool versus alternatives such as generate_person, generate_consistent_person, or generate_title. The description does not state whether this is appropriate for standalone random names, consistent names, or full person objects, leaving the agent to guess.

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 supply readOnlyHint=true and destructiveHint=false, and the word 'synthetic' adds the important context that the data is fabricated and not real. The description does not elaborate on randomness, optional-parameter effects, or any generation constraints, but for a safe read-only generator 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 a single front-loaded sentence that wastes no words. It is concise while still containing the key 'synthetic' qualifier.

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 generator with zero required parameters and an output schema, the description is minimally sufficient to invoke the tool. However, it lacks any guidance on parameter effect or when to choose it over sibling generators, so it is 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%, and the description says nothing about how gender or language affect the generated next-of-kin record. The parameter names and enum values are self-explanatory, but the description fails to compensate for the schema's lack of descriptions.

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 ('Generates') and a distinct resource ('synthetic next-of-kin record'), so an agent can tell this apart from the many person/name generators. It is clear, though it does not explicitly contrast it with siblings such as generate_person or generate_detailed_person.

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

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

There is no when-to-use guidance, no mention of alternatives, and no conditions for choosing this tool over related generators. An agent gets no help deciding between this and generate_person/consistent_person options.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds 'synthetic' and 'test data only' but does not describe output characteristics or generation behavior beyond that; the output schema handles return details.

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

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

A single sentence with no filler, front-loading the action and resource and ending with the test-data constraint. Every word earns its place.

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

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

For a zero-parameter generator with annotations and an output schema, the description provides the necessary purpose and usage constraint. No material information an agent needs to invoke this tool correctly is missing.

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

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

The tool has zero parameters, so there is nothing for the description to add about parameter meanings. The zero-parameter baseline of 4 applies.

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

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

The description states a specific verb ('generates') and resource ('a synthetic NIN'), and scopes it clearly to test data. This makes the tool's purpose unambiguous and distinct from the many other generate_* siblings.

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

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

'For test data only' provides clear context and an implicit exclusion of production use. It does not name alternatives or explicit when-not conditions, but the tool is a standalone generator with no obvious competing sibling.

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 and non-destructive behavior. The description adds valuable behavioral detail: it returns 10 records by default and accepts an optional positive count. 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?

A single sentence that front-loads the action and resource, then provides only the essential behavioral details. Every part earns its place 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?

With an output schema present, an annotations block, and full parameter documentation, the description covers the main operational facts: what is produced, in what form, and the default volume. A minor gap is the lack of explicit differentiation from the many similar generation siblings, but the 'basic' qualifier partially compensates.

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 already documents both parameters fully (100% coverage), giving a baseline of 3. The description adds meaning by stating the default count of 10 when count is omitted and clarifying that count is optional.

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

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

States a specific verb and resource: 'Generates an array of basic composite synthetic person records.' The 'basic composite' qualifier gives some distinction from siblings like generate_detailed_people, though it does not explicitly name 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 description implies when to use the tool through the words 'basic composite' and the plural array behavior, but it never explicitly states when to choose this over generate_person, generate_detailed_people, or generate_consistent_people. No exclusions or alternative routing are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it returns 'one synthetic object', which is somewhat redundant with the output schema. It also mentions 'composite' and 'identity and contact fields', giving a sense of the record's scope, but does not discuss determinism via the optional seed or any edge cases. With annotations carrying the safety burden, the description adds modest contextual value but not rich behavioral detail.

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 three sentences with no filler. It front-loads the primary purpose, immediately gives a usage exclusion, and then lists parameters and return type. Every sentence earns its place; it is efficient and scannable for an agent.

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

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

With an output schema present and full parameter documentation, the description covers the essentials: what it does, when to prefer alternatives, and the nature of the return. It does not mention the difference from generate_people (plural) or generate_consistent_person, but the 'basic composite' label plus the atomic-tool hint provide enough context for an agent to make a reasonable choice. It is largely complete for a read-only synthetic generator.

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

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

Schema coverage is 100% — every parameter (seed, gender, language) has a description and gender/language have enums. The description repeats the enums but adds no new meaning beyond the schema. For instance, it does not explain the interplay between seed and reproducibility beyond what the schema says. Baseline 3 is appropriate when the schema fully documents parameters and the description contributes little extra.

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 generates 'one basic composite person record with identity and contact fields', using a specific verb and resource. It distinguishes itself from atomic tools by explicitly naming the alternative condition ('Use atomic tools when you need only one attribute'), and the word 'basic' hints at the difference from more detailed variants like generate_detailed_person. This makes the tool's purpose 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 clear guidance on when NOT to use this tool: when only a single attribute is needed, use atomic tools instead. This is a valuable exclusion. However, it does not address other closely related siblings such as generate_people (plural), generate_consistent_person, or generate_detailed_person, leaving the agent to infer the distinctions. It gives one strong usage rule but lacks a complete routing strategy across all siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the detail that the number is 'Nigerian' and 'synthetic', which is useful context beyond annotations. However, it does not disclose any other behavioral aspects such as randomness, determinism, or output format, but with annotations covering safety, the description adds some value.

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

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

The description is a single, efficient sentence with no fluff. It front-loads the core purpose and is appropriately sized for a tool with a single optional parameter. Every word 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?

Given the tool's simplicity and that annotations and an output schema exist, the description is still incomplete. It omits usage guidance and the network parameter semantics, which are critical for correct invocation. An agent cannot fully determine when and how to use this tool based on the description alone.

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 description coverage is 0%, so the description must compensate for explaining the 'network' parameter. It does not mention the parameter at all, leaving the agent to infer from the enum (mtn, glo, airtel, 9mobile) without knowing how it affects the output. The enum is somewhat self-explanatory, but the description fails to connect it to the tool's behavior.

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 ('generates') and a specific resource ('synthetic Nigerian phone number'). It clearly distinguishes from sibling tools that generate people, NINs, vehicle records, etc. However, it doesn't mention the optional network parameter, which is part of the tool's purpose, so it falls short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios (e.g., needing a phone number, or when to use generate_consistent_person for correlated data). No exclusions or comparisons are given.

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 convey read-only, non-destructive behavior, and the description adds the useful fact that the record is synthetic. However, it says nothing about randomness, consistency, or dependencies, so it provides adequate but not rich behavioral context given 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?

One short sentence, front-loaded with the core action and object, with no wasted words. It is as concise as a description can be, though it sacrifices explanatory depth elsewhere.

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

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

The tool is simple (one optional enum parameter) and has an output schema and annotations, so the description is close to sufficient. However, the lack of usage guidance and parameter semantics leaves gaps that an agent must resolve by inference, making this a minimum-viable description.

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

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

Schema description coverage is 0% and the description never mentions the 'level' parameter or how it affects the generated salary. The enum values are self-explanatory, but the description adds no meaning beyond the schema and fails to compensate for the missing parameter 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?

Description uses a clear verb ('generates') and names the resource ('synthetic salary record'), so an agent knows what it produces. It does not explicitly differentiate from sibling generators like generate_work_record, which could also involve salary data, so it falls short of the top score.

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?

No when-to-use or when-not-to-use guidance is given; the description states only what the tool does. With many sibling generator tools available, there is no mention of alternatives or conditions, so an agent must infer selection from the name and schema.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns a predefined list of Nigerian states, but it does not say whether the result is exhaustive, ordered, or stable across calls. Since the tool has no parameters and a simple read-only behavior, a 3 is appropriate.

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

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

A single, front-loaded sentence that conveys the essential behavior with no filler. Every word earns its place.

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

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

For a parameterless, read-only tool with an output schema, the description is nearly complete: it says what is returned and the domain. It loses one point for not clarifying what 'available' means (e.g., all 36 states plus FCT) or whether the ordering/count is guaranteed, though these are minor given the output schema and lack of 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?

The tool accepts zero parameters, so the schema's empty properties object covers 100% of the parameter surface. The description need not add parameter details, and the baseline for a zero-parameter tool is 4.

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

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

States a specific verb ('Returns') and a specific resource ('available Nigerian states'), making it easily distinguishable from siblings like generate_lgas or generate_person. Even though the title already conveys the topic, the description clarifies that the tool returns the full available set rather than generating a single random value.

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?

No guidance on when to use this tool instead of sibling generators such as generate_lgas, generate_address, or generate_person. The context is clear, but there are no exclusions, prerequisites, or routing hints.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat those. The description adds the Nigerian cultural context (which is helpful) but doesn't disclose output format or any conditional behavior (e.g., whether gender affects the title). With annotations covering the safety profile, the description adds minimal extra behavioral context.

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

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

The description is a single sentence, concise and to the point. It provides the core purpose without any fluff, making it easy to parse.

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 only one optional parameter and an output schema (which likely defines the title format), the description is relatively complete for a simple generation tool. However, it could benefit from specifying the cultural scope (Nigerian) and how gender is used, but the output schema mitigates 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?

The schema has one optional parameter 'gender' with enum values, and schema coverage is 0%. The description does not explain that 'gender' controls title variation (e.g., male vs. female titles). While the enum values are self-explanatory, the description fails to clarify how gender affects the generated title, leaving the agent to infer from common knowledge.

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 'Generates a synthetic Nigerian title' clearly states the verb (generates) and resource (Nigerian title), making the tool's purpose clear. It distinguishes from siblings like generate_name, which generates a full name, though it doesn't explicitly contrast with generate_name.

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?

No guidance on when to use this tool versus alternatives like generate_name or generate_person. The description does not mention that generate_title might be used for title-only generation, nor does it note any constraints (e.g., gender-based). Context implies standalone title generation, but no explicit usage context or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the important context that the record is synthetic and Nigerian-specified, which goes beyond annotations, but it does not disclose details like output structure or possible variability. This is adequate but not rich.

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

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

A single sentence that immediately states the tool's purpose with the key qualifying details ('synthetic', 'Nigerian', 'university record'). There is no wasted wording and the structure efficiently front-loads the action and object.

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 parameterless generation tool with an output schema available, this description is fully sufficient. An agent knows what to expect (a synthetic Nigerian university record) and can rely on the output schema for return structure. No additional context is needed.

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?

There are zero parameters, so the schema provides full 100% coverage and there is nothing for the description to clarify. The baseline for no parameters is 4, and the description appropriately focuses on the output rather than any parameters.

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 ('Generates') and a specific resource ('synthetic Nigerian university record'), making the tool's function unmistakable. It is distinct from siblings like generate_person or generate_education_record by targeting a university entity, even though it does not explicitly name the differentiating sibling.

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 a synthetic Nigerian university record is needed, which is clear from the purpose. However, it provides no explicit guidance about when not to use it or how it differs from overlapping siblings such as generate_education_record or generate_company.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the key behavioral fact that the record is synthetic and Nigerian. It does not go deeper into randomness, determinism, or state-dependent behavior, but for a simple generator with an output schema 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 a single front-loaded sentence with no filler or repeated title words. Every word 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?

Given the tool's low complexity, an output schema, and safety annotations, the definition is mostly adequate. It is incomplete only in usage guidance and the meaning/effect of the optional state parameter, which prevent it from being fully self-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?

Schema description coverage is 0%, and the description never mentions the only parameter, state. The word 'Nigerian' hints at the domain but does not explain what values state accepts or how it affects the generated record, so the parameter semantics are not compensated outside 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 ('Generates') and resource ('synthetic Nigerian vehicle record'), which is clear and distinct enough from sibling tools like generate_license_plate. It does not explicitly contrast itself with sibling generate_* tools, so it falls just short of a 5.

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

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

The use case is implied: call this when a synthetic Nigerian vehicle record is needed. However, there is no explicit guidance about when to prefer this over sibling record generators (e.g., generate_education_record, generate_work_record) or what the optional state parameter is for.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by explaining the generation logic: the job starts after graduation and seniority/position/salary scale with years of experience. This gives the agent insight into how the output is derived, which is beyond the annotations.

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

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

Two concise sentences with no redundancy. The core purpose is front-loaded, and the logic explanation is tight. 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?

The tool is simple with two well-documented parameters and an output schema that presumably describes the return structure. The description covers the essential generation logic. It does not mention optionality or edge cases, but given the schema and output schema richness, nothing critical is missing 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?

Schema coverage is 100% (both parameters have descriptions). The description reinforces the relationship between age and graduationYear ('job starts after the degree') and introduces that seniority/position/salary depend on experience, which is not fully captured in the schema descriptions. This adds meaningful context for correctly interpreting the parameters.

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

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

States a specific verb ('Generates') and resource ('synthetic work record'), and the description explains the relationship between the inputs (age, graduation year) and the output (job starts after degree, seniority/position/salary follow experience). This clearly distinguishes it from sibling tools like generate_salary or generate_title, which target individual fields.

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 use case (generating a complete work record) but does not explicitly contrast it with alternatives like generate_salary or generate_title, nor does it state when not to use this tool. It provides the input logic but no explicit routing guidance beyond the obvious composite nature of the tool.

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