Server Quality Checklist

Tool Scores

• nexusapi_list_modelsA
  3.7/5.0
  Behavior2/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 catalog is 'currently exposed' but doesn't state what the response contains, whether it's read-only, or any side effects. This is a gap for an unannotated tool.

  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?

  A single, efficiently worded sentence that front-loads the core action and immediately introduces optional filters. 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?

  The description is adequate for a simple two-parameter list tool with complete schema documentation. However, without an output schema, the agent is left guessing about return format. It also lacks any usage guidance beyond the basic scope.

  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 both parameters are already well-documented. The description's mention of 'kind or search text' adds no new meaning beyond the schema's own descriptions. Baseline 3 is appropriate.

  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 purpose with a specific verb ('list'), resource ('models'), and scope ('public NexusAPI catalog'). It also distinguishes itself from siblings (get schema, generate, get task) by being the only listing/discovery tool.

  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 conveys clear context: it lists available models, optionally filtered by kind or search. While it doesn't explicitly say when to use this vs alternatives, the purpose is so distinct from siblings that usage is obvious.

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

• nexusapi_get_taskA
  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. 'Get' implies a read-only operation, and the mention of 'status, result or error' hints at varying response states. However, it does not explicitly state non-destructive behavior, prerequisites (beyond task_id), error handling for invalid IDs, or whether the operation might block. 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.

  Conciseness5/5

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

  The description is a single sentence, 11 words, that front-loads the action ('Get') and specifies what is retrieved. Every word contributes meaning; there is no fluff or redundancy. This is a model of conciseness.

  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 tool is simple with one parameter and no output schema. The description sufficiently explains the purpose and return types (status, result, error). It could benefit from explicitly stating the expected usage flow (e.g., 'call after nexusapi_generate'), but given the simplicity and sibling list, it is nearly complete.

  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%: task_id is described as 'Task id returned by nexusapi_generate,' which already provides clear semantics. The tool description adds no additional parameter context beyond referencing 'previously created task.' Since the schema does the heavy lifting, a baseline score of 3 is appropriate.

  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 verb 'Get' and the specific resource: 'status, result or error of a previously created NexusAPI generation task.' It directly distinguishes this from sibling tools like nexusapi_generate (which creates) and nexusapi_list_models/get_model_schema (which list models). The purpose is 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 phrase 'previously created NexusAPI generation task' implies usage after calling nexusapi_generate, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, such as checking other task-related endpoints or using list_models for model info. Still, the sequencing is well implied.

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

• nexusapi_generateA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the task is paid, asynchronous, and requires user approval due to potential billing. This goes beyond simply restating the title and provides important operational context, though it does not mention response format or failure modes.

  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, consisting of two sentences. The first sentence states the purpose, and the second adds crucial usage guidance. Every word earns its place, and the structure is clear and front-loaded.

  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 complexity (asynchronous, billable, nested parameters) and lack of output schema, the description provides essential context by warning about billing and instructing the schema-first workflow. However, it omits details about the return value or how to poll for results, leaving some gaps that are partially mitigated by the sibling tool nexusapi_get_task.

  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 input schema already thoroughly documents all parameters (prompt, model_name, parameters). The description does not add additional meaning beyond what the schema provides, thus aligning with the baseline score of 3.

  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 creates a paid asynchronous generation task, which is a specific verb+resource combination. It distinguishes itself from sibling tools like nexusapi_list_models, nexusapi_get_model_schema, and nexusapi_get_task by focusing on the generation task creation.

  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 explicit usage guidance by instructing to call nexusapi_get_model_schema first and to ask for user approval due to billable generation. This gives clear context on when to use the tool and the necessary prerequisite steps, though it does not explicitly mention alternatives or when not to use.

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

• nexusapi_get_model_schemaA
  4.2/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. It explicitly states 'Read' and 'live,' disclosing a non-mutating, current lookup. It does not mention error behavior or response structure, but for a simple read-only schema fetch this is reasonable.

  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 a single, front-loaded sentence that states the action and purpose without wasted words. 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 one-parameter tool with no output schema, the description is largely complete: it names what is retrieved and when to use it. It could mention that model names come from `nexusapi_list_models`, but the sibling context and schema description cover the essential workflow.

  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 already fully documents the single `model_name` parameter with type, minLength, and description. The description adds no extra semantic detail beyond referring to it as 'model id,' so with 100% schema coverage, the baseline 3 applies.

  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 identifies the exact resource ('live OpenAPI parameter schema for one NexusAPI model id') and intent ('before constructing a generation request'). This clearly distinguishes it from sibling tools like list_models or generate.

  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 phrase 'before constructing a generation request' gives a clear when-to-use signal and situates the tool in the generation workflow. It does not explicitly name alternatives or exclusions, but the context is enough to avoid confusion with siblings.

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