Server Quality Checklist

Tool Scores

• search_workersB
  3.4/5.0
  Behavior3/5

  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 does disclose the returned fields and the multi-match disambiguation behavior, which is genuinely useful, but says nothing about match semantics (exact vs partial, case sensitivity), empty-result behavior, or read-only nature beyond the word 'search'.

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

  Conciseness4/5

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

  Two tight sentences with the primary action front-loaded and the return behavior appended. Every sentence contributes, though the return-field listing is somewhat redundant given an output schema exists.

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

  Completeness3/5

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

  The presence of an output schema lowers the bar for explaining return values, and the description covers the disambiguation case. However, for a search tool it omits essential call-correctness details like matching semantics and empty-result handling, leaving a noticeable gap.

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

  Parameters3/5

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

  Only one parameter at 0% schema description coverage, so the description must compensate. 'By name' restates the parameter name without clarifying expected format (full name, partial, surname-only) or matching behavior, adding little beyond what the schema's field title conveys.

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

  Purpose4/5

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

  States a specific verb and resource ('Search the Workday worker population by name') and ties it to a downstream goal ('find a template worker'), which distinguishes it from synthesize_test_hire and generate_synthetic_identity. It does not explicitly contrast with get_worker_template, which is the nearest sibling, so it falls short of 5.

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

  Usage Guidelines3/5

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

  The phrase 'find a template worker' implies this is a lookup step preceding get_worker_template, but no when-to-use, prerequisites, or explicit alternative is named. Usage is left to inference rather than stated.

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

• get_worker_templateA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the behavioral burden. It discloses that the tool returns cloneable fields (job profile, supervisory org, country) and requires prior user confirmation, which is useful. However, it does not specify permission requirements, whether the operation is read-only, or any rate limits, leaving significant behavioral gaps for a tool with zero annotation coverage.

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

  Conciseness4/5

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

  The description is concise, front-loading the core action in the first sentence and then the usage condition in the second. Both sentences earn their place, though the parenthetical explanation could be slightly tighter.

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

  Completeness3/5

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

  For a single-parameter tool with no output schema and no annotations, the description covers the purpose and usage condition but lacks behavioral details such as read-only nature, permissions, and error handling. It is adequate but not fully complete given the lack of structured metadata.

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

  Parameters3/5

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

  With 0% schema description coverage and one required parameter, the description implies that employee_id identifies the confirmed template worker but does not add format, syntax, or source details beyond what the schema name suggests. It partially compensates by linking the parameter to the confirmation step, but not enough to fully document it.

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

  Purpose4/5

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

  The description clearly states a specific verb and resource: fetching a confirmed template worker's cloneable fields via Get_Workers, and enumerates what is returned (job profile, supervisory org, country). It distinguishes the purpose from siblings like search_workers by emphasizing the confirmed template selection, though it does not name a direct sibling as an alternative.

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

  Usage Guidelines5/5

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

  Explicitly states when to use it: 'Call this only after the user has confirmed exactly which worker (by employee_id) to use as the template.' This provides a clear prerequisite and timing condition, effectively guiding the agent on when and when not to invoke the tool.

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

• generate_synthetic_identityA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It does disclose locale resolution behavior ('locale-appropriate name where supported, falling back to en_US'), which is genuinely useful, but says nothing about randomness, uniqueness guarantees, persistence, or whether re-invocation produces different values.

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

  Conciseness4/5

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

  Front-loaded with the output, then usage rationale, then parameter semantics in a logical progression. Slightly verbose in the 'literally duplicating the template worker's name' clause, but no sentence is wasted.

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

  Completeness4/5

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

  With one param, no annotations, and no output schema, the description covers purpose, usage context, the single parameter, and names the generated fields. It could state the return shape (single object vs separate values), but it is otherwise complete for a simple generator.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description must compensate, and it does fully: it specifies the exact format (ISO 3166-1 alpha-3), gives concrete examples ('USA', 'GBR', 'JPN'), and explains the parameter's effect (locale-based name selection with en_US fallback). This adds far more than the bare 'Country' string field.

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

  Purpose4/5

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

  States a specific verb (generate) and precise resource (synthetic first name, last name, email). It implicitly distinguishes itself from get_worker_template by explaining it avoids 'literally duplicating the template worker's name,' but does not name or contrast with the sibling tools directly.

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

  Usage Guidelines4/5

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

  Gives a clear when-to-use scenario: 'give the new hire its own identity instead of literally duplicating the template worker's name,' anchoring it in the hire-synthesis workflow. No explicit when-not or named alternative (e.g. synthesize_test_hire) is provided.

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

• synthesize_test_hireA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does well: it discloses the mutation, the mandatory user-confirmation gate, and that Hire_Employee is the underlying mechanism. It omits permissions/scopes required, reversibility or undo behavior, and failure semantics, leaving real gaps for a destructive operation.

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

  Conciseness5/5

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

  Front-loads the action and the critical safety gate in the first sentence, then handles parameter clarifications in compact clauses. Every sentence earns its place with no repetition of the schema.

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

  Completeness3/5

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

  For a 9-parameter mutating tool with no annotations and no output schema, the description nails the behavioral essentials (mutation + confirmation) but leaves the majority of parameters undocumented and says nothing about results, errors, or permissions. Adequate but with clear gaps.

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

  Parameters3/5

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

  Schema description coverage is 0% and there are 9 parameters, so the description must compensate. It documents only three: country as an ISO 3166-1 alpha-3 code, hire_date defaulting to today in ISO format, and employee_id as optional/auto-assigned. job_profile, supervisory_org, position_id, email, first_name, and last_name remain entirely undefined.

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

  Purpose5/5

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

  States a specific verb and resource ('Submit the user-approved hire payload to the tenant via Hire_Employee') and explicitly positions itself against siblings by noting it is 'the one tool in this server that actually mutates the tenant', distinguishing it from search_workers, get_worker_template, and generate_synthetic_identity.

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

  Usage Guidelines4/5

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

  Gives a clear precondition ('Only call this after the user has explicitly confirmed the proposed fields'), which is strong usage guidance for an irreversible action. It does not name an alternative tool or describe a when-not-to-use path beyond that gate, 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.