Server Quality Checklist

Tool Scores

• auth_loginB
  3.3/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 discloses the authentication method (username/password) and return value (success status and masked token info), which are useful behavioral traits. However, it lacks details on error handling, rate limits, session management, or security implications (e.g., token expiration).

  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 highly concise and front-loaded, consisting of two sentences that directly state the tool's function and return value. Every word contributes essential information without redundancy or fluff, making it efficient for an agent to parse.

  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?

  Given the tool's complexity (authentication with credentials) and lack of annotations or output schema, the description is minimally complete. It covers the basic action and return but omits critical context like error cases, token usage, or integration with other tools (e.g., 'auth_refresh'). For a security-sensitive operation, more detail would be beneficial.

  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%, with clear documentation for both parameters (username as email, password as password). The description adds no additional parameter semantics beyond what the schema provides, such as format constraints or validation rules. The baseline score of 3 reflects adequate coverage by the schema alone.

  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's purpose: 'Authenticate with Evaluar using username and password.' It specifies the action (authenticate), the target system (Evaluar), and the method (username/password). However, it doesn't explicitly differentiate from sibling tools like 'auth_refresh' which likely handles token renewal rather than initial authentication.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (e.g., needing credentials), when not to use it (e.g., if already authenticated), or how it relates to sibling tools like 'auth_refresh'. The agent must infer usage context 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.

• position_searchB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context beyond the schema by specifying that it returns 'top 10 matching active positions sorted by creation date,' which clarifies scope and sorting. However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a mutation-free but potentially complex search 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?

  The description is extremely concise and front-loaded, consisting of two sentences that efficiently convey the action, resource, and key behavioral traits (like result limit and sorting). Every word earns its place with zero waste.

  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?

  Given the tool's low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and some behavior (like sorting and limit), but lacks output details (e.g., what fields are returned) and broader context (e.g., authentication needs), which could hinder an agent's effective use.

  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 the schema already documents the single 'query' parameter thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., no extra syntax or format details), meeting the baseline for high schema coverage without enhancement.

  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's purpose with a specific verb ('Search') and resource ('positions by name'), making it immediately understandable. However, it doesn't differentiate itself from potential sibling search tools (though none are listed among siblings), which prevents a perfect score.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (like authentication), exclusions, or comparisons with other tools (e.g., how it differs from 'process_assign_position' or 'process_create' if relevant). This leaves the agent without contextual usage cues.

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

• process_launchB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the prerequisite (position assignment) and the return value (summary URL), which adds useful context beyond basic functionality. However, it doesn't address important behavioral aspects like error conditions, authentication requirements, or what happens during the launch operation.

  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 appropriately brief (two sentences) and front-loaded with the core functionality. Both sentences provide valuable information (the action and the prerequisite, then the return value), with no wasted words or redundant information.

  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 annotations and no output schema, the description provides the essential information about what the tool does, a prerequisite, and what it returns. However, it lacks details about the launch operation's behavior, potential side effects, or error handling that would be helpful 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?

  The input schema has 100% description coverage, with the single parameter 'processId' clearly documented in the schema. The description doesn't add any additional parameter information beyond what the schema already provides, so it meets the baseline expectation but doesn't enhance parameter understanding.

  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 action ('Launch an eTalent process') and resource ('eTalent process'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'process_create' or 'process_assign_position' beyond the launch action.

  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 provides one important prerequisite ('The process must have a position assigned first'), which gives some context for when to use this tool. However, it doesn't offer guidance on when to choose this tool versus alternatives like 'process_create' or 'process_assign_position', nor does it specify when NOT to use it.

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

• process_assign_positionA
  3.5/5.0
  Behavior2/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 of behavioral disclosure. It mentions that it 'associates' a position, implying a mutation/write operation, but doesn't disclose critical details like required permissions, whether the association is reversible, error conditions, or what happens if parameters are invalid. For a mutation tool with zero annotation coverage, this is a significant gap.

  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 concise sentences with zero waste. The first sentence states the purpose, and the second provides essential usage guidance, making it front-loaded and efficiently structured.

  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?

  Given the tool's complexity (a mutation with 4 required parameters), lack of annotations, and no output schema, the description is minimally adequate. It covers purpose and basic usage but lacks details on behavioral traits, error handling, or return values. It meets the minimum viable threshold but has clear gaps in completeness.

  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 schema description coverage is 100%, so the schema already documents all four parameters with their sources (e.g., 'from process_create', 'from position_search'). The description adds no additional parameter semantics beyond what the schema provides, but it reinforces the dependency on 'position_search' for position details, which aligns with the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 action ('Associate a position with an existing eTalent process') and specifies the resource ('eTalent process'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from potential siblings like 'process_create' or 'process_launch' beyond the specific association action.

  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 provides clear contextual guidance by stating 'Get position details from position_search first,' which implies a prerequisite workflow. It doesn't explicitly state when not to use this tool or name alternatives, but the guidance is practical and helpful for correct usage.

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

• process_createA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates a new process and returns an ID, but doesn't mention permissions required, whether the creation is idempotent, error conditions, or rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

  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 perfectly concise with two sentences that each earn their place: the first states the core functionality and outcome, the second explains the return value. There's zero waste or redundancy, making it highly efficient and front-loaded.

  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?

  Given this is a mutation tool with no annotations and no output schema, the description provides basic purpose and return value but lacks details on error handling, authentication requirements, or what 'subsequent operations' entail. It's minimally viable but has clear gaps for a tool that creates resources.

  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 the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.

  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 specific action ('Create a new eTalent process'), the resource ('eTalent process'), and the resulting status ('in DRAFT status'), distinguishing it from siblings like process_launch or process_assign_position by focusing on initial creation rather than subsequent operations.

  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 for creating a new process in draft status, but lacks explicit guidance on when to use this versus alternatives like process_launch or prerequisites such as authentication. It mentions 'subsequent operations' but doesn't specify what those might be or when to choose this tool over others.

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

• company_listA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions authentication requirement ('Must be logged in first'), which is useful. However, it lacks details on behavior such as pagination, rate limits, error handling, or return format. For a read operation with zero annotation coverage, this is a significant gap, scoring 2.

  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 action ('List all companies...') followed by a prerequisite. Every word earns its place with no redundancy or fluff, making it highly efficient and well-structured.

  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?

  Given the tool's simplicity (0 parameters, no output schema, no annotations), the description covers the basic purpose and authentication need. However, it lacks details on behavioral aspects like return format or error handling, which are important for a list operation. It's minimally viable but has clear gaps, scoring 3.

  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 tool has 0 parameters, and schema description coverage is 100%. The description doesn't need to add parameter details, so it naturally compensates by focusing on usage context. Baseline for 0 params is 4, as the description provides adequate semantic context without parameter clutter.

  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 verb ('List') and resource ('companies'), specifying scope ('all companies available for the authenticated user'). It distinguishes from siblings like 'company_select' by focusing on listing rather than selecting. However, it doesn't explicitly differentiate from other list-like siblings (e.g., 'position_search' might also list positions), keeping it at 4.

  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 provides clear context: 'Must be logged in first' indicates a prerequisite, and 'for the authenticated user' implies user-specific access. It doesn't explicitly state when not to use it or name alternatives (e.g., vs. 'company_select'), but the context is sufficient for basic guidance, warranting a 4.

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

• company_selectA
  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 of behavioral disclosure. It mentions the tool changes the 'active company' context, which implies state mutation, but doesn't specify whether this affects other operations, requires authentication, or has side effects. The description adds basic context but lacks details about permissions, error conditions, or persistence of the selection.

  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 extremely concise and well-structured with just two sentences. The first sentence states the core purpose, and the second provides essential usage guidance. There's no wasted language, and both sentences earn their place by adding distinct value.

  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?

  Given the tool's moderate complexity (state-changing operation with one parameter) and the absence of both annotations and an output schema, the description does a reasonably complete job. It explains what the tool does and provides workflow guidance, though it could benefit from more behavioral details like authentication requirements or error handling. The lack of output schema means return values aren't documented, but the description compensates somewhat with context.

  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 has 100% description coverage, with the parameter 'companyId' clearly documented as 'The ID of the company to select.' The description doesn't add any additional parameter semantics beyond what the schema provides, such as format examples or where to obtain valid IDs. With complete schema coverage, the baseline score of 3 is appropriate.

  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's purpose: 'Select the active company to work with.' This specifies the verb ('select') and resource ('active company'), making it immediately understandable. However, it doesn't explicitly distinguish this tool from its siblings beyond mentioning company_list, so it doesn't fully achieve the highest level of sibling differentiation.

  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 provides explicit usage guidance: 'Use company_list first to see available options.' This clearly indicates when to use this tool (after obtaining company IDs from company_list) and references a specific alternative tool, helping the agent understand the proper workflow sequence.

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

• auth_refreshA
  4.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 of behavioral disclosure. It mentions the action ('Refresh') but lacks details on permissions, rate limits, or what happens on failure. However, it does add useful context about token expiration, which is valuable beyond a bare description.

  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 zero waste: the first states the purpose, and the second provides usage guidelines. It is front-loaded and efficiently conveys all necessary information without redundancy or 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?

  Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is nearly complete for its purpose. It covers what the tool does and when to use it, though it could benefit from mentioning behavioral aspects like error handling or token persistence. The lack of output schema is not critical here.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it implies the tool operates on an implicit token context, slightly enhancing understanding. Baseline is 4 for zero parameters.

  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 specific action ('Refresh') and resource ('authentication token'), distinguishing it from sibling tools like 'auth_login' which likely obtains a token initially. It precisely defines what the tool does without being vague or tautological.

  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 explicitly provides when to use this tool ('when the current token is about to expire'), offering clear guidance on its context and distinguishing it from alternatives like 'auth_login' for initial authentication. This helps the agent select the correct tool based on token state.

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