Server Quality Checklist

Tool Scores

• list_filter_valuesA
  4.3/5.0
  Behavior4/5

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

  Annotations already cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context: vocabulary is company-specific (e.g., 'Full-time' vs 'Full Time') and department filters are checked against current openings because no vocabulary is published. This goes beyond the annotations and helps the agent understand the data's nature.

  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?

  The description is two sentences, front-loaded with the action, and efficiently explains the tool's purpose, the per-company variation, and the department exception. Every sentence adds valuable context without redundancy.

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

  Completeness5/5

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

  For a simple read-only tool with an output schema present, the description sufficiently covers what the tool does, why it is used, and an important edge case (department). The combination of annotations, schema descriptions, and the description gives an agent everything needed 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.

  Parameters3/5

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

  The input schema describes all parameters with 100% coverage, including defaults (fields defaults to all three, instance defaults to global, company_slug is required). The description underscores the purpose of fields (team, location, commitment) but adds no new parameter-level syntax or details. Baseline 3 is appropriate when schema carries the semantic load.

  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?

  The description clearly states the tool's function: 'List the team, location and commitment wordings one company uses on Lever.' It names the specific verb ('List'), the resource (filter wordings for a company), and the scope (team, location, commitment), distinguishing it from sibling tools like search_jobs and get_job.

  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?

  The description explains when this tool is valuable: when building filters that need company-specific wording ('so a filter can carry the words that company publishes'). It also provides context by noting that department vocabulary is not published and is handled differently, implicitly guiding the agent away from expecting it. It does not explicitly name alternatives but the use case is clear.

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

• get_jobA
  4.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavior beyond annotations: it specifies what is returned (advert, named sections, salary) and warns that a site on both instances may hold different openings, helping the agent interpret results correctly. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose. Every clause contributes: the first sentence defines the output, the second clarifies parameter provenance and cross-instance behavior. No redundant wording or filler.

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

  Completeness5/5

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

  For a focused read tool with an output schema and strong annotations, the description is complete. It states what the tool returns, how to obtain parameters, and a critical edge case (differing data per instance). No obvious missing context given the tool's simplicity and the presence of an output schema.

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

  Parameters4/5

  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 adds semantic value by explaining that company_slug and instance should be the ones 'the row carried', linking them to a search result. The instance nuance (different data per instance) further clarifies the parameter's meaning. This is a clear addition beyond the schema.

  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?

  The description uses a specific verb ('Read') and names the exact resource ('one Lever opening in full'), and distinguishes this tool from siblings by emphasizing the full detail retrieval vs. searching or listing (search_jobs, list_filter_values). It also names the key output components (advert, sections, salary), making the purpose unambiguous.

  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?

  The description establishes a clear context: use this when you need the full content of a specific opening, identified by a row from a prior search. It also provides a key nuance about instance-specific data. However, it does not explicitly mention when not to use it or name alternatives, though the sibling list implies search_jobs for discovery.

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

• resolve_companyA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: it reports every instance that answered and probes names without reading a single board, clarifying the operational behavior and lightweight nature 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.

  Conciseness5/5

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

  The description is two sentences, with the first sentence stating the core function and the second providing usage guidance. Every sentence contributes meaning, with no fluff or repetition of structured data.

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

  Completeness5/5

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

  Given the simple parameter schema, comprehensive annotations, and presence of an output schema, the description covers all necessary aspects: purpose, usage differentiation, and behavioral traits. It does not need to explain return values because an output schema exists.

  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?

  The single parameter 'names' is fully described in the schema (100% coverage), so the description does not need to add parameter details. It aligns with the schema by referring to 'company names' and 'Lever site names', but adds no additional syntax or format information, matching the baseline for full schema coverage.

  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?

  The description uses a specific verb ('turn') and resource ('company names' to 'Lever site names'), clearly stating the mapping action and output. It also distinguishes itself from search_jobs by noting that this tool checks which companies are on Lever without reading boards.

  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 this tool versus search_jobs: search_jobs resolves names on its own, while this tool is for checking which of several companies are on Lever. It also explains the efficiency advantage (probes without reading boards).

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

• search_jobsA
  4.8/5.0
  Behavior5/5

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

  The description goes well beyond the annotations by disclosing request costs (3 requests for found, up to 9 for resistant, 1 second each), exact wording requirements for Lever filters, local vs server-side filtering behavior, per-company limit application, and pagination depth for posted_within_days. This provides important operational context that annotations alone would not convey.

  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?

  Every sentence in the description carries unique, actionable information. It is dense but not verbose, and the purpose is front-loaded in the first sentence. There is no wasted text; all details about costs, filtering, and pagination are necessary for correct use.

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

  Completeness5/5

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

  Given the tool's complexity (14 parameters, pagination, rate limits), the description covers the key behavioral aspects thoroughly: rate costs, exact wording constraints, local vs server-side filtering, per-company limit semantics, and pagination. The output schema (not shown) presumably handles return fields, so the description need not duplicate that; it fills the gaps around usage costs and filter behavior comprehensively.

  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?

  Although the schema covers 100% of parameters, the description adds critical behavioral semantics: companies are converted to site names, certain params require exact Lever wording, others are applied locally, limit is per company, and posted_within_days walks multiple pages. This meaningfully enriches the schema definitions and explains edge cases.

  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?

  The description opens with a specific verb+resource: 'Search the openings published by named companies on Lever.' This clearly distinguishes it from sibling tools like get_job (which fetches a single job) and resolve_company (which resolves company names). The scope is precise about searching across multiple named companies.

  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?

  It provides clear context about the domain (Lever) and how parameters behave differently (server-side vs local filtering). It does not explicitly state when to use this tool over get_job or resolve_company, but the scope is obvious from the description. There is no exclusionary guidance, but the context is strong enough to infer appropriate use.

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