Server Quality Checklist

Tool Scores

• list_categoriesA
  3.6/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 behavioral disclosure burden. It does disclose the paginated nature and rough default page count, which is useful, but it does not mention response shape, ordering, error behavior, or whether the operation has any side effects.

  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 entire description is one efficient sentence that front-loads the core purpose and adds the key limitation inline. Every word contributes and there is no filler or repetition of the title.

  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?

  For a simple paginated list operation with only two self-explanatory pagination parameters and no output schema, the description is reasonably complete. It gives the main purpose, the payload clue (IDs), and the pagination behavior. It only lacks minor detail about the exact response envelope and potential edge cases.

  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%, so the description must compensate. It adds meaning by explaining pagination and the approximate number of pages, indicating that page and per_page control a bounded paged listing, but it does not clarify how pages are indexed, when pagination should be used, or what each category object contains.

  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 the tool lists all job categories and includes their IDs, which is a specific verb+resource combination. It does not explicitly distinguish itself from the sibling job-search tools, though the category focus makes the distinction reasonably clear.

  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 pagination notice implies the agent should expect paged results and likely needs to iterate pages to get all categories, but there is no explicit guidance about when to choose this over sibling tools or how it supports jobs_by_category. Usage context is implied rather than stated.

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

• jobs_by_companyA
  3.7/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 behavioral context. It correctly states the tool returns open jobs and that the company identifier is a slug, but it does not describe response format, pagination behavior, or any other operational traits. For a simple read-only list style tool this is adequate but not richly transparent.

  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 short, well structured, and every sentence carries meaning. The core behavior is stated first, followed by the essential slug guidance, with 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.

  Completeness4/5

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

  For a simple list-by-company tool with full schema parameter documentation and no output schema, the description provides enough context for an agent to select and invoke it. It could be more complete with explicit sibling differentiation or a note about return content, but the current level is sufficient for the tool's low complexity.

  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 schema already documents all four parameters. The description adds extra value by explaining what the company value actually is: a slug, with a concrete example ('2brains' for getonbrd.com/companies/2brains).

  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 identifies the action ('List open jobs') and the resource scope ('published by one company'), so an agent understands what the tool does. It does not explicitly name sibling tools, but the company-specific framing distinguishes it from the broader search and category tools.

  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 description implies the right usage scenario: use it when jobs for a specific company are needed, using the company slug. However, it does not explicitly contrast it with search_jobs or jobs_by_category, or state when those alternatives should be preferred.

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

• search_jobsA
  4/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 behavioral burden. It discloses that results are compact objects containing salary band, remote modality, countries, application count, and the job description itself, so no extra call is needed for triage. This provides meaningful behavioral context beyond simply stating it's a search.

  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?

  Two sentences, no fluff. The first sentence front-loads the core purpose and scope; the second adds valuable info about return content and triage efficiency. Every phrase earns its place.

  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?

  For a search tool with no output schema, the description covers the essential output fields and the presence of the description for triage. It doesn't clarify the interaction between the `full` parameter and the description inclusion, but given the schema documents that parameter, this is a minor gap. Overall, enough context is provided for an agent to use it 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?

  Schema description coverage is 100%, so each parameter (query, full, page, per_page) is already documented with examples and defaults. The description adds no parameter-specific semantics; it only reinforces the overall behavior. Baseline of 3 applies because the schema does the heavy lifting.

  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 states a specific verb and resource: 'Full-text search over Get on Board job listings' with a clear domain (LATAM tech jobs). It distinguishes itself from siblings like jobs_by_category and jobs_by_company by emphasizing full-text search across all listings, not a filtered browse.

  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 description implies usage as a general full-text search tool but does not explicitly say when to prefer it over siblings or when not to use it. It mentions 'no extra call is needed to triage,' hinting at an advantage over get_job, but it lacks direct comparisons or exclusion criteria.

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

• jobs_by_categoryA
  4.2/5.0
  Behavior3/5

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

  No annotations were provided, so the description carries the burden. It clarifies 'open jobs' and the grouped by category behavior, but it doesn't mention pagination, full vs preview content, or whether it returns any global metadata. The schema partially covers these, so the description could add more context without contradicting anything.

  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?

  Condensed and front-loaded. The first sentence defines the core purpose, the second provides actionable parameter guidance with examples. Every word earns its place; no fluff.

  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?

  The schema covers parameter details and defaults, and the description adds the missing conceptual context (category ID source). Since this is a list operation without complex mutation or side effects, the description plus schema provide sufficient for correct invocation. Sibling tool names give extra orientation.

  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?

  The schema already describes all four parameters, so the baseline is 3. The description adds value by giving concrete example category IDs and explicitly mentioning that category must be a valid ID, making it easier for an agent to construct correct calls.

  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?

  Description states a specific verb (List), resource (open jobs), and constraint (in one category). It also provides concrete category ID examples, distinguishing it from get_job (single job) and list_categories (category metadata).

  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 explicitly tells the agent to use list_categories to get valid IDs, which is a direct usage guidance for a prerequisite. It doesn't explicitly contrast with get_job, but the 'in one category' phrasing makes the scope clear enough.

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

• get_jobA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the disclosure burden. It clearly states the auth requirement and the 401 failure case, and implies the returned content may lack descriptions by recommending search_jobs for that. It could go further by explicitly stating whether descriptions are missing, but for a simple fetch-by-id tool this is reasonably transparent.

  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 fits useful guidance into one compact sentence, front-loading the core purpose before addressing authentication and the alternative. Every clause earns its place.

  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?

  The description explains what the tool does, how to authenticate, and which sibling to prefer. It is complete enough for a low-complexity one-parameter fetch, though there is no output schema and the description does not explicitly state the job content/detail fields returned.

  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?

  The schema covers the parameter with an example, and the description adds critical extra meaning: the id is the slug from the job's URL. This teaches the agent what kind of value to pass, going beyond the raw 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 states a specific verb and resource: 'Fetch one job by id (the slug in its URL).' It also distinguishes itself from the sibling search_jobs by noting that search_jobs already includes descriptions, which clarifies why an agent might choose one over the other.

  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?

  The description gives explicit usage context: use this tool to fetch a single job by its slug, and prefer search_jobs when descriptions are needed. It also warns about the required GETONBRD_API_TOKEN and the 401 result without it, giving the agent concrete conditions for invocation.

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