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

With no annotations, the description carries the full burden, and it does disclose two genuinely useful traits: max_tokens is capped at 4096 per call and usage is metered (billable). It does not cover auth requirements, rate limits, error behavior, or what happens when a model ID is invalid, which leaves meaningful gaps for a billed network call.

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

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

Three short sentences, front-loaded with what the tool does, followed by the two constraints that matter (token cap, metering). No filler, no repetition of the schema.

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

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

For a simple four-parameter chat proxy with no output schema, the description covers the return shape (reply + token usage) and the token ceiling. It is still missing model discovery, temperature guidance, and failure modes, so an agent can call it but not fully predict behavior.

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

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

Schema coverage is only 25% — just the 'model' field has a description, and it is circular ('Model ID to call'). The description adds nothing about the messages array structure, role semantics, or temperature behavior, and its 4096 cap restates the schema's maximum rather than adding meaning. Low coverage with no compensating detail puts this below the 3 baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: calls the Badgr AI API as an OpenAI-compatible chat completion and returns the reply plus token usage. That is unambiguous and clearly distinct from the deployment/lifecycle siblings (deploy_model, badgr_run, check_result). It stops short of explicitly naming where an alternative might apply, which keeps it at 4 rather than 5.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no exclusions. Nothing tells the agent when to prefer this over launch_agent_task or deploy_model, nor what prerequisites exist (model availability, credentials). The 'OpenAI-compatible chat completion' phrase only implies usage; the agent must infer it.

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

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

No annotations are provided, so the description carries the full burden. "Terminate" implies a destructive, likely irreversible action, but the description never says whether data/volumes are lost, whether shutdown is graceful, whether billing stops immediately, or how a missing/already-terminated deployment is handled.

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

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

One short sentence with the action and its effect front-loaded; zero filler. The only issue is that more content would have been justified, not that anything is wasted.

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

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 output schema this is minimally sufficient to invoke correctly, but for an unannotated destructive operation the description should disclose irreversibility and any data-loss semantics, which it does not.

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

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

Schema description coverage is 100% and the single parameter is documented as "Deployment ID to terminate," so the baseline of 3 applies. The description adds nothing about ID format or how to obtain a valid deployment_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ("Terminate") plus specific resource ("a Badgr deployment") and an explicit outcome ("stop billing"). It is clearly the teardown counterpart to badgr_run/badgr_serve, though it never names those siblings directly.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to call this versus badgr_status or badgr_run, no prerequisites, and no exclusions. The agent must infer that this is the stop/decommission operation and that it should only be used on a deployment that should no longer exist.

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

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

With no annotations, the description carries the full burden but discloses nothing behavioral: no indication of whether the call blocks until completion, whether logs are tailed or truncated, how large a payload to expect, or whether the deployment must still be live. Only the schema hint that deployment_id comes from badgr_run/badgr_serve adds any operational context.

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

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

One short, front-loaded sentence with no filler. It is efficient, though the brevity reflects under-specification rather than tight editing.

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

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

A single-parameter read tool with a fully documented schema, so the core invocation is answerable. But with no output schema and no annotation coverage, the description should say something about what logs come back and in what form; that gap leaves it merely adequate.

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

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

Schema description coverage is 100% and the single parameter is documented with its provenance (returned by badgr_run or badgr_serve). The description adds nothing beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Fetch) and resource (logs) scoped to a Badgr deployment, which is clear on its own. However, it never distinguishes this from sibling tools like badgr_status or badgr_down, which an agent must guess between when diagnosing a deployment.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus badgr_status (health) or badgr_down (teardown), and no prerequisites such as the deployment needing to exist or be running. The agent is left to infer that logs are only meaningful after badgr_run/badgr_serve.

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

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

With no annotations, the description must carry the full burden. It does useful work by disclosing the return fields and the $5/hr hard cap plus a $1/hr human-confirmation gate — meaningful safety context. However it never says whether the call blocks until the job finishes or returns immediately after submission, nor what happens on capacity failure, which is the key behavioral unknown for a job-launch tool.

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

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

Three short sentences: what it does, what it returns, what the limits are. Front-loaded and every sentence adds a distinct fact. No filler.

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

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

No output schema exists, so listing deployment_id/status/receipt_id/logs_url is valuable, and the cost guardrails fill the annotation gap. Missing only the synchronous-vs-asynchronous execution model and what a minimal valid invocation looks like given zero required parameters.

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

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

Schema coverage is 100%, so baseline is 3; the description earns a bump by restating the max_price_per_hour ceiling alongside the operational rule that ties it to user confirmation. It does not add meaning for gpu, image, region, or command beyond the schema, but it does link the price cap to behavior rather than just a constraint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb and resource: 'Run a one-off GPU job via Badgr'. The word 'one-off' implicitly distinguishes it from badgr_serve (long-running serving), but no sibling is named explicitly. An agent can tell what it does without reading the schema, but must infer the boundary with badgr_serve.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

'One-off' hints at the exclusion versus persistent serving tools like badgr_serve/deploy_model, but that contrast is never stated. The cost-confirmation rule ('always confirm with the user before running jobs that cost > $1/hr') is a concrete, actionable usage constraint. No explicit when-not guidance or named alternative.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the persistent billing lifecycle ('stays up (billing runs) until badgr_down'), hard price cap, required runtime limit, and the need to confirm with the user. It also names key return values. Minor gaps remain, such as failure modes or provisioning time, but core safety and lifecycle traits are surfaced.

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

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

The description is tightly structured: it front-loads the purpose, then covers return values, lifecycle, hard limits, and a safety confirmation in five efficient sentences. Every sentence contributes actionable information with no waste.

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

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

Given the absence of annotations and output schema, the description provides substantial context: purpose, return fields, billing lifecycle, required safety parameter, hard price cap, and user-confirmation rule. It is nearly complete for safe invocation, though it does not clarify behavior on provisioning failure or how the endpoint relates to similar sibling tools.

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

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 seven parameters in detail. The description reinforces the required nature of max_runtime_minutes and the $5/hr price cap, but these are also present in the schema descriptions. It adds little parameter-specific meaning beyond the schema baseline, so a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Provision a persistent OpenAI-compatible endpoint for an LLM model.' This is clear and actionable. However, it does not distinguish this tool from sibling tools like deploy_model or run_workload, which could also be used for model deployment. The reference to badgr_down clarifies lifecycle but not when to choose badgr_serve over other launching tools.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: it is for persistent serving, billing runs until badgr_down is called, max_runtime_minutes is required, and the agent must confirm with the user before serving. This covers when to use and a key prerequisite. It stops short of explicitly comparing with alternatives like deploy_model or run_workload, so no full when-not guidance is provided.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses two traits: the result is filtered to 'active' deployments only, and it is scoped to the caller's account rather than all accounts. It does not say whether results are paginated, what 'active' means, or what the response looks like.

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

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

One sentence, front-loaded with the verb and scope, with no filler. Every clause earns its place by narrowing the result set.

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

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

For a zero-parameter read tool this is close to adequate, but with no annotations and no output schema the agent still cannot tell what a status entry contains or how to interpret 'active'. A brief note on return shape would complete it.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly implies no filtering arguments are needed because account scope is implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('active Badgr GPU deployments') scoped to 'this account'. An agent can distinguish it from badgr_run/badgr_down/badgr_logs by the listing intent, though it never names those siblings explicitly.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the discovery/status check before or after run/down/serve, but the description gives no explicit when-to-use or when-not-to-use guidance and names no alternative.

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

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

With no annotations, the description carries the full burden, and it partially meets it by naming the returned fields (status, cost so far, verification output, receipt, logs). It does not say whether the call is a safe read, whether it polls or blocks, whether cost is cumulative, or how log output is bounded — gaps that matter for a monitoring tool with no annotations and no output schema.

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

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

A single front-loaded sentence with a colon-delimited list of return contents; every clause adds information and nothing is padded.

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

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

Adequate but incomplete: it names the returned fields, which is valuable given there is no output schema, but it leaves log_lines unexplained and omits behavioral traits (read-only nature, cost semantics, log truncation) for a tool with zero annotation coverage.

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

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

Schema coverage is only 50%: job_id is documented in both schema and description, but log_lines appears nowhere in the description and has no schema description (only type/min/max/default). The description does not compensate for the undocumented parameter, which controls how much log output is returned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Check an agent task') and enumerates what it reports: status, cost, verification output, receipt, log lines. Ties it explicitly to launch_agent_task, which separates it from generic status siblings. It doesn't differentiate against check_result or badgr_status, keeping it short of a 5.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

'started with launch_agent_task' gives clear implied context — use it to poll a task you launched. But there is no explicit when-not-to-use guidance and no mention of the check_result sibling that could plausibly serve a similar role, so an agent still has to infer routing.

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

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

With no annotations, the description must carry the behavioral burden; it does communicate that this is a state-read plus log-fetch and that leaving a deployment running accrues billing. It omits what 'state' values are possible, whether this call itself has side effects or cost, and any latency or retry characteristics.

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

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

Three short sentences, no waste, with purpose front-loaded before the sequencing hint and the billing warning. Every sentence carries actionable information.

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

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 should explain what comes back; it names 'state' and 'log lines' but does not enumerate states or indicate log formatting. For a status-check tool this leaves a meaningful gap, though the lifecycle guidance is solid.

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

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

deployment_id provenance is added beyond the schema ('returned by run_workload or deploy_model'). log_lines is left entirely to the schema, which already documents default 50 and the 0-500 range at 100% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: check state of one Badgr deployment plus fetch recent log lines. It ties itself to the run_workload/deploy_model lifecycle, though it does not distinguish itself from siblings badgr_status or badgr_logs, which appear to overlap.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('use after run_workload or deploy_model, with the returned deployment_id') and a follow-up action ('call badgr_down when finished so billing stops'). No exclusion versus badgr_status/badgr_logs is stated, so it stops short of full alternative routing.

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

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

With no annotations, the description carries the full burden and does well: it discloses persistent billing, the teardown dependency on badgr_down, hard cost and runtime limits, and a mandatory user confirmation step. It stops short of describing authentication needs or failure modes, leaving some behavioral gaps for a provisioning operation.

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

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

Five sentences, front-loaded with the core action, then return values, lifecycle, limits, and a safety instruction. Every sentence earns its place with no repetition or filler.

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

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

Given no annotations and no output schema, the description supplies the critical missing context: return fields, persistent billing, teardown mechanism, and required safeguards. It could be more complete by noting what happens on provisioning failure or whether the endpoint requires credentials, but the essential information for correct invocation is present.

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

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 seven parameters. The description reinforces the required nature of max_runtime_minutes and the $5/hr cap, but adds no syntax, format, or edge-case detail beyond what the schema provides. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Provision a persistent OpenAI-compatible endpoint for an LLM model.' It distinguishes the tool from teardown sibling badgr_down via lifecycle context, but does not explicitly name or contrast with other provisioning alternatives like badgr_serve or run_workload.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied through the lifecycle note ('stays up until badgr_down is called') and the requirement to confirm with the user before serving. However, there is no explicit guidance on when to prefer this tool over siblings such as badgr_serve or run_workload, nor are there exclusions or prerequisites beyond the required runtime cap.

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

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

With no annotations, the description carries the full load and does well: it discloses hard cost/runtime caps, that verification runs `check`, that a job_id is returned, and that user confirmation is required. It omits key side-effect details – whether the agent commits/pushes/opens PRs on the repo and what happens on failure or timeout – which matters for a mutating launch.

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

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

Front-loaded with purpose, then verification, limits, return/workflow, and the confirmation rule – every sentence carries information an agent needs. No filler.

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

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

Covers the launch-verify-poll-receipt lifecycle and the required-parameter emphasis, which is enough to invoke it correctly, and there's no output schema to explain. The gap is agent-selection guidance and failure/side-effect semantics for a tool that can mutate a repository.

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

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

Schema coverage is 67%. The description restates the max_cost and max_runtime_minutes constraints that the schema already enforces (maximum 5, maximum 60) rather than adding guidance. It says nothing about the `agent` enum (claude/codex/cline/...), its default, or how `repository`/`instruction` should be formed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Launch an autonomous coding agent on a GitHub repository') plus the verification mechanism, and names the sibling (check_launch_task) used to follow up. An agent can tell exactly what this does relative to check_launch_task or the badgr_* tools.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete workflow rule ('Always confirm with the user before launching') and explicitly routes follow-up polling to check_launch_task. It stops short of stating when NOT to use it (e.g. vs. run_workload or a specific agent choice), so it's not a full 5.

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

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

With no annotations, the description carries the full burden and does reasonably well: it declares the return fields (deployment_id, status, receipt_id, logs_url), a hard spend cap, and a user-confirmation gate for costly jobs. It omits lifecycle behavior an agent would want — whether the job is billed until stopped, how to terminate it (presumably badgr_down), and whether the call blocks or returns immediately.

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

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

Three tight sentences: capability and return values first, then the hard limit, then the confirmation rule. Nothing is wasted and the most decision-relevant constraint is front-loaded.

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

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

For a zero-annotation, zero-output-schema job launcher, the description covers what the tool does, what it returns, and the cost guardrails. The remaining gap is post-launch lifecycle and cancellation guidance, which matters for a billable GPU job but is a single missing piece rather than a systemic hole.

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

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

Schema description coverage is 100%, so all seven parameters are documented in the schema itself, making 3 the baseline. The description only restates the $5/hr ceiling already encoded as the schema maximum, adding no syntax, units, or interaction detail beyond structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Run a one-off GPU job via Badgr') and the word 'one-off' implicitly separates it from persistent-serving siblings like badgr_serve. However, it never distinguishes itself from the confusingly similar sibling badgr_run or from deploy_model, which an agent would need in order to choose correctly.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

One concrete operational rule is given ('Always confirm with the user before running jobs that cost > $1/hr'), which is genuinely useful gating behavior. But there is no explicit statement of when to prefer badgr_run, badgr_serve, or deploy_model, so the usage boundary is only implied by 'one-off'.

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