Server Quality Checklist

Tool Scores

• get_job_resultB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds 'latest job by default,' which is already in the schema's job parameter, and 'logs and results' tells the agent what to expect in return. It does not reveal whether jobs must be completed or how large logs might be, but given annotation coverage this is acceptable.

  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 concise phrase that conveys the core function and default behavior with zero wasted words. It is front-loaded with the key output ('Logs and results').

  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?

  With no output schema, the description should carry more return-value context; 'logs and results' is a minimal but acceptable indication. Missing are the deployment_id/job relationship, whether jobs can be in-progress, and what a job result contains. The required parameter is clear from the schema, but overall completeness is adequate yet not strong.

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

  Parameters2/5

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

  Schema description coverage is 50%, with only job described and deployment_id left bare. The tool description does not clarify deployment_id's meaning or its relationship to job, nor does it explain the format of a job address. The description adds little beyond what the schema already provides.

  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 title supplies the verb 'Get' and the description names the resource: logs and results of a deployment job. The scope is clear (deployment job) and it notes the default of latest job, but it does not explicitly contrast with siblings like get_deployment or get_deployment_events.

  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?

  No guidance is given for when to choose this tool over get_deployment or get_deployment_events. The only hint is 'latest job by default,' which is more about default behavior than usage routing. There is no when-not-to-use or alternative recommendation.

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

• list_deploymentsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds mild behavioral context (newest-first ordering and included fields) but does not disclose pagination behavior, response shape, or filtering defaults beyond the schema.

  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 efficient sentence with the most important information (what is listed, ordering, included fields) front-loaded. 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, read-only list operation with strong annotations and a schema that documents filters, the description is largely complete. It could mention pagination or explicitly say it returns a list of deployment summaries, but the ordering and fields plus schema cover most agent needs.

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

  Parameters2/5

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

  Schema description coverage is moderate (two of three parameters documented) and the description adds no parameter-level meaning beyond the schema. limit is only described by its default/min/max, and the description does not clarify how search or status filters interact.

  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?

  Description states a clear verb and resource ('Deployments on this account'), specifies newest-first ordering and visible fields (status, strategy, active jobs, timeout), so an agent can tell it lists deployments. It does not explicitly contrast itself with siblings like get_deployment or list_templates, so it stops short of full differentiation.

  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?

  No guidance is given for when to choose this tool over alternatives; there are no exclusions or mentions of get_deployment for single-deployment detail, create_deployment, or estimate_deployment. The one-sentence description only states what it returns, leaving selection context entirely to inference.

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

• extend_deploymentA
  3.6/5.0
  Behavior3/5

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

  Annotations already convey that this is a non-read, non-idempotent, non-destructive operation. The description adds the useful side effect that longer timeouts reserve more credits, but it does not clarify whether the new timeout replaces the current remaining time or only affects future runs, and it does not address idempotency 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?

  Two sentences with no filler: the first states the action and target, the second gives the key consequence. The most important information is 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?

  For a low-complexity tool with two required scalar parameters and no output schema, the description is minimally viable. However, it omits whether the deployment must already exist, whether the timeout change takes effect immediately, and what a successful call returns or implies.

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

  Parameters2/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 only that timeout_minutes is 'in minutes' and that deployment_id refers to 'a deployment', which largely restates the parameter names. It does not explain how to obtain a valid deployment_id or any expected format.

  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 and resource: 'Sets a new timeout in minutes for a deployment'. It clearly identifies what the tool does and distinguishes it from deployment lifecycle siblings like create, stop, start, or wait. The minimum constraint is also stated.

  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 tool should be used to change an existing deployment's timeout, but it does not state when to prefer this over create_deployment or whether the deployment must be in a particular state. The credit-reservation note is a consequence, not an explicit usage guideline.

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

• list_templatesA
  3.6/5.0
  Behavior3/5

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

  Annotations already cover the safe read-only, idempotent nature of the tool. The description adds useful domain context—that some templates require a variant id when deploying—but does not elaborate on tool behavior such as response shape, pagination, or filtering effects. This is acceptable given the rich annotations, but not exceptional.

  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 compact sentences with no filler. Examples are front-loaded for quick comprehension, and the variant warning earns its place as a deployment-relevant caveat.

  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 read-only listing tool with one optional documented parameter and strong annotations, the description is nearly sufficient. It could explicitly say that the tool returns the full list of available templates and how search narrows results, but the intent is clear enough from the name, title, and examples.

  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 optional search parameter is already fully documented in the input schema with a clear example. The description adds no extra meaning about the search parameter, so the schema carries the burden. Baseline 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 identifies the resource—ready-to-run Nosana templates—and gives concrete examples of what the user will see. It stops short of using an explicit verb like 'list' and does not distinguish itself from get_template, so it misses the top score.

  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 this tool is for discovering available deployable templates, especially with the variant warning at the end, but it does not explicitly say when to choose list_templates over get_template or another sibling. The 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.

• list_gpusA
  3.8/5.0
  Behavior4/5

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

  Annotations already establish the operation is read-only, idempotent, and non-destructive. The description adds useful behavioral detail: prices include network fee and match deploy.nosana.com, idle hosts are current, and template-fit filtering only applies when a template is supplied. 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 entire description isone sentence that front-loads the output fields and key caveats (network fee, current availability, conditional template fit). There is no filler or duplication of schema content.

  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 read-only list tool, the description covers the main output shape and the conditional template behavior, and annotations cover safety.It omits any mention of the variant parameter and does not describe queue/community result effects, leaving some reliance on input-schema descriptions; still adequate for selection and invocation.

  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 80%, so the schema already documents four of five parameters and the description reinforces the template behavior. The variant parameter has no schema description and is not explained in the description, so there is a small remaining semantic gap; the description adds context but does not carry the parameter documentation burden.

  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 names the resource (GPU markets) and the exact fields returned (price per hour, idle hosts, VRAM, template fit), so an agent knows what the tool does. It does not explicitly differentiate from sibling tools like list_templates or estimate_deployment, so it is clear but not a 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 description implies when the tool is useful — for checking current GPU pricing, availability, and template compatibility — and the schema adds that include_queue is slower and include_community broadens the market set. It never states when to prefer this over sibling tools or when not to use it, so usage guidance is largely implicit.

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

• get_deploymentA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations by specifying that endpoint status includes both tunnel online state and actual service responsiveness, plus recent jobs and events. This gives the agent a clearer picture of what the call will return.

  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, efficient sentence that front-loads the main purpose ('current status of a deployment') and lists the included categories without any filler or repetition. Every word 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 simple read-only status tool with one parameter, the description covers the key return categories and endpoint health semantics. There is no output schema, so listing endpoints, jobs, and events is important and mostly sufficient. It could be more explicit about how jobs/events are represented or paginated, but this is a minor gap.

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

  Parameters2/5

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

  The schema has 0% description coverage for the single required parameter, deployment_id, and the description does not explain what deployment_id is, where to obtain it, or its format. The parameter is somewhat self-evident from the tool name, but with no schema description and no compensation in the tool description, the agent must infer its meaning.

  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 what the tool returns: current status of a single deployment, including endpoint health (tunnel online and service responsiveness), recent jobs, and recent events. This is specific about resource and scope, and distinguishes it from broader listing tools like list_deployments and from get_deployment_events, which covers only events.

  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 this tool is for checking the current status of one deployment, but it does not explicitly say when to prefer it over siblings like get_deployment_events, wait_for_deployment, or list_deployments. There are no alternative names or exclusions, leaving usage to inference.

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

• get_deployment_eventsA
  3.9/5.0
  Behavior4/5

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

  Annotations already cover the read-only, idempotent, non-destructive profile, so the description adds value by revealing behavior beyond that: the log is ordered newest-first and includes scheduler lifecycle and error events. There is no contradiction with 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?

  One short is sentence that puts the core concept first, then adds selective examples and ordering. 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 read-only event listing, the description plus the schema and annotations cover the essential facts: what is returned, the order, the required parameter, and the optional limit with defaults. It is slightly incomplete only in that limit is not semantically described, but overall it is adequate for correct invocation.

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

  Parameters2/5

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

  With schema_description_coverage at 0%, the description was expected to compensate. It only indirectly implies deployment_id by saying 'for a deployment', and it says nothing about the limit parameter, its default, or its purpose. The schema provides type/constraints but not semantics, so this is a real gap.

  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: 'Scheduler event log for a deployment', and clarifies the content by listing example event kinds ('job listed, stopped, errors such as insufficient funds or bad timeout'). The 'Newest first' ordering also helps distinguish it from tools that return deployment state. This clearly differentiates it from get_deployment and get_job_result.

  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 this is the tool to use when an agent needs a deployment's event history, and gives an idea of what those events include. However, it never explicitly states when not to use it or whether get_job_result or get_deployment would be more appropriate for specific needs.

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

• get_templateA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destrictive behavior, so the description doesn't need to restate safety. It adds useful behavioral context by specifying what kinds of details are returned and noting that the job definition is included only optionally. No contradiction with annotations exists.

  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?

  One dense, front-loaded sentence states scope and then lists the return categories with a concrete hardware example. Every clause earns its place; there is no filler or 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?

  There is no output schema, so the description carries the burden of explaining return content, and it does a reasonably complete job for the main detail fields. However, it omits the behavior of include_readme and doesn't clarify whether variant is meant to narrow a template or can be fetched independently. Those gaps matter for an agent trying to invoke this 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?

  With 50% schema description coverage, the schema documents template and variant but leaves include_readme and include_job_definition undocumented. The description partially compensates by mapping 'optionally the job definition' to include_job_definition, but it never mentions include_readme or explains how template and variant relate.

  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 'Details of one template or variant,' which identifies both the resource and the scope, then enumerates the exact detail categories returned: VRAM, hardware notes, web endpoint, variants, and optionally the job definition. This clearly separates it from list_templates and deployment-focused siblings.

  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 gives clear context: use this tool when you need details about a single template or variant, not for balances, GPU listings, or deployments. It stops short of explicitly naming alternatives or listing when-not-to-use cases, so it misses a full 5.

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

• create_deploymentA
  4.2/5.0
  Behavior4/5

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

  Annotations only provide generic hints (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds crucial behavioral context beyond these: 'SPENDS CREDITS,' requiring user-approved confirm=true, and returning a deployment id followed by polling wait_for_deployment. This is strong disclosure for a credit-spending action.

  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?

  Three sentences, each earning its place: the first front-loads the credit warning and core action; the second states the mandatory confirmation workflow; the third explains the return value and follow-up polling. No filler, no redundant restatement 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 complex tool with 14 parameters, a nested job_definition object, and no output schema, the description covers the essential high-level workflow: estimate → confirm → create/start → poll. It does not redundantly list every parameter, leaving that to the schema. It could have mentioned edge cases like draft mode (start=false), but the schema handles that, so this is reasonably 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%, so the schema fully documents all 14 parameters. The description mentions 'template or job definition' and 'chosen GPU' and 'confirm=true', but these are already elaborated in the schema with examples and conditions. It adds no substantive meaning beyond the structured 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 states a specific action and resource: 'Creates a Nosana deployment from a template or job definition on the chosen GPU and starts it.' It clearly distinguishes this from the sibling start_deployment (which starts an existing deployment) by combining create and start. It also references estimate_deployment and wait_for_deployment, further separating its role in the workflow.

  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 gives explicit usage guidance: 'Requires confirm=true, which you must only pass after the user has seen the estimate from estimate_deployment and agreed.' It also maps the lifecycle after creation: 'then poll wait_for_deployment until the endpoint is ready or the job completes.' It does not explicitly state when not to use it in favor of start_deployment, but the create-and-start framing implies it.

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

• start_deploymentA
  4.2/5.0
  Behavior4/5

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

  The description adds important behavioral context beyond the annotations: it warns that the operation SPENDS CREDITS and that user confirmation is required via confirm=true. These are meaningful side effects not visible in the schema or annotations. It does not contradict any annotation.

  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 short, dense sentences with the credit warning front-loaded and the confirm requirement stated immediately. Every sentence adds essential information with no filler.

  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 covers the key preconditions: credit cost, required confirm, and eligible deployment states. With no output schema, it does not describe the response or whether the deployment start is asynchronous, but the operation is simple enough that this is a minor gap rather than a correctness blocker.

  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 explains confirm=true and implies deployment_id from 'a deployment', but it does not explicitly describe deployment_id's meaning or the effect of confirm=false. This is partial but minimally viable compensation for the undocumented 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 (Starts), a specific resource (a DRAFT or STOPPED deployment), and the exact behavior (again with its existing settings). This clearly distinguishes it from sibling tools like create_deployment and stop_deployment without needing to inspect the schema.

  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 says the tool starts only DRAFT or STOPPED deployments and requires confirm=true after user agreement, giving a clear when-to-use condition. It does not explicitly name alternatives, but the eligibility criteria make the usage context clear.

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

• wait_for_deploymentA
  4.2/5.0
  Behavior5/5

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

  Annotations already cover read-only, idempotent, and non-destructive traits, and the description adds substantial behavior beyond that: blocking duration bounds, the full outcome set (online/completed/failed/pending), and payload hints (ready URLs, logs, scheduler error). It reinforces idempotentHint by stating repeated calls are safe, and nothing contradicts 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?

  Three tight sentences with zero filler. The blocking behavior and key parameter are front-loaded in sentence one, outcomes are compressed into a list-style sentence, and the safety note is a short clause. Every sentence 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?

  With no output schema, the description correctly takes on explaining return values: it enumerates all four outcomes and what each carries (URLs, logs, error, retry signal). Minor gaps - deployment_id is never explicitly defined and behavior for an invalid/nonexistent deployment_id is unaddressed - but for a simple two-parameter wait tool the essentials are covered.

  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 explains what max_seconds controls ('Blocks up to max_seconds') and its bounds, but deployment_id is never explicitly tied to a parameter - only implied by 'watches a deployment'. For a two-parameter tool this is partial compensation, not full.

  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 ('watches'/'bloks') and resource ('a deployment'), and the blocking behavior stands in clear opposition to sibling single-shot reads like get_deployment or get_deployment_events. The named outcome vocabulary makes the tool's purpose unambiguous and distinguishes it from the get_* family.

  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 gives useful context - it blocks up to a timeout, returns 'pending' for retry, and is safe to call repeatedly - which implies when an agent would want it. However, it never explicitly states when to prefer this over siblings like get_deployment or get_job_result, nor gives exclusions (e.g., use a get_* tool when you don't want to block), so usage guidance is implied rather than explicit.

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

• stop_deploymentA
  4.3/5.0
  Behavior4/5

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

  Beyond the annotations, the description reveals that running jobs are terminated and billing stops, which is meaningful behavioral context. It is consistent with destructiveHint=true and readOnlyHint=false, though it could add more about reversibility.

  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 compact sentences front-load the action and consequences, then give usage guidance. No filler or 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 single-parameter stop operation with annotations covering safety and idempotency, the description supplies the key behavioral and usage context. Nothing essential is missing.

  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%, but the only required parameter is deployment_id and its role is inferable from 'Stops a deployment.' The description does not explicitly explain the parameter, yet with one self-documenting string field the gap is minor.

  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 precise verb-resource pair: 'Stops a deployment and its running jobs,' and adds the consequential effect that billing stops. This clearly distinguishes it from sibling tools like start_deployment or extend_deployment.

  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 gives explicit conditions for use: 'when the user is done or when a deployment can never schedule.' It does not name alternatives or exclusions explicitly, but the criteria are clear enough for an agent to select this over start/list operations.

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

• estimate_deploymentA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint/idempotentHint/non-destructive; the description reinforces that and adds real behavioral detail: it returns warnings for known failure modes (VRAM, non-Blackwell, insufficient credits, no idle hosts) and computes one-timeout-window credit cost. This is more than the annotations alone provide.

  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?

  Three dense sentences, front-loaded with the key concept 'Dry run' and a clear behavioral distinction, then specifics and a next-action recommendation. No wasted words or repetition of schema content.

  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 complex 9-parameter tool with no output schema, the description conveys what is returned (cost + warnings) and the side-effect-free nature of the call. It slightly under-specifies how strategy/schedule affect the estimate for non-SIMPLE strategies, but the schema's strategy descriptions and the tool's pre-flight role make it adequate.

  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% parameter description coverage and documents all defaults/enums, so the schema does the heavy lifting. The description only adds high-level references to template/variant, GPU, and timeout window, which is helpful but not necessary because each parameter is already fully described.

  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 names a specific verb ('resolve', 'validate', 'return the cost'), resource (deployment plan) and outcome (credits for one timeout window plus warnings). It explicitly contrasts with create_deployment ('Nothing is created'), so an agent can distinguish it from its sibling.

  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?

  'Call this before create_deployment and show the user the cost' is an explicit when-to-use instruction with the relevant alternative named. 'Dry run' and 'validate the plan' also signal it is the pre-flight planning tool rather than a mutating action.

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

• get_balanceA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful detail about the components of the balance and the 1 credit = 1 USD pricing, which helps the agent interpret the result. No contradiction or missing behavioral concern is apparent.

  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 no filler. The core subject is stated first, followed by the useful explanatory details about credit categories and pricing. Every sentence contributes to correct invocation and interpretation.

  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 zero-parameter read-only tool, the description covers the important semantics: account scope, balance components, and pricing unit. There is no output schema, but the listed categories strongly imply what the response reports. It does not spell out the exact response format, but the tool is simple enough that this is a minor gap.

  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 zero parameters, so there is no schema detail to compensate for, and the baseline is 4. The description still adds value by clarifying what 'balance' means and scope it to the API key's account. No parameter explanations are needed.

  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 identifies the resource: credits on the Nosana account behind the API key. It decomposes the meaning into assigned, reserved, settled, and available, and the title adds the 'get balance' verb. This is unambiguous and distinct from the deployment-focused sibling tools.

  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: this tool reads the credit balance for the account associated with the API key. It does not name alternatives, but none of the sibling tools serve the same purpose, so no exclusions are necessary. A brief 'use this to check account credits' would be marginally clearer, but the context is sufficient.

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