Together AI MCP by usefulapi

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

Annotations already declare destructiveHint=true, so the agent knows this is a mutating operation. The description adds the precondition that the job must not have finished plus the underlying endpoint, but says nothing about idempotency, whether partial results are lost, or what happens if the job already completed.

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?

Two short sentences, action and precondition front-loaded, with the endpoint reference appended compactly. Nothing 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 mutation with annotations covering the destructive profile and no output schema, this is nearly sufficient. The main residual gap is behavior on already-finished or nonexistent jobs.

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% for the single batch_id parameter, so the schema already carries the full parameter meaning. The description adds no format or example detail beyond it, which is the expected 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 (Cancel) and resource (batch job), and the name itself separates it from the sibling together_cancel_fine_tune. It does not explicitly name the alternative, so it stops short of full sibling differentiation.

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 clause 'that has not finished' implies the applicable precondition, but there is no explicit when-to-use/when-not guidance and no mention of alternatives such as together_cancel_fine_tune or together_get_batch for status checks.

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?

The destructiveHint annotation already flags this as destructive, and the description adds valuable behavioral context: cancellation is irreversible and a new job can resume from the last checkpoint. It does not cover auth requirements or response behavior, but the irreversibility disclosure is the key behavior an agent needs.

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?

Two tight sentences plus an endpoint reference, with the action and its irreversibility front-loaded. Every sentence adds useful information without 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?

For a simple one-parameter cancel operation with an existing destructive annotation and no output schema, the description covers purpose, irreversibility, and recovery. It omits minor details like possible response format, but these are not essential for correct invocation.

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% and the single parameter is fully documented in the schema. The description adds no additional parameter syntax or meaning beyond referring to a job id implicitly, so the baseline of 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 (cancel) and resource (fine-tuning job), distinguishing it from sibling operations like get, list, and create. The API endpoint reinforces the exact action being performed.

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?

Clearly indicates the tool is for canceling a running job and provides the critical consequence that it cannot be resumed, along with the checkpoint recovery path. It does not explicitly state when not to use it versus alternatives, but the purpose is narrow enough that no exclusions are necessary.

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?

Annotations only supply destructiveHint=true, so the description carries most of the behavioral burden and does well: it discloses the non-streaming constraint and the per-token billing model, both real behavioral traits a calling agent must account for. It does not contradict the annotation; it simply omits return-shape details.

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 the core action and constraint, with zero filler. Each sentence earns its place by adding a distinct fact (what it does, streaming behavior, endpoint routing, underlying API).

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 10-parameter inference tool with no output schema, the description covers the essentials an agent needs to invoke it correctly (billing, non-streaming, endpoint addressing). It does not describe the response shape or sampling-parameter tradeoffs, but those are standard for a chat-completions API.

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 60%, so the schema handles most parameters, but the description adds genuinely non-obvious meaning for 'model' by explaining the `<project_slug>/<endpoint_slug>` form used for dedicated endpoints. The remaining sampling parameters (temperature, top_p, seed, etc.) are left to the schema.

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+resource ('Run a chat completion on a Together model') and immediately distinguishes itself from siblings like together_create_embeddings and together_generate_image by naming the exact modality. The scope qualifiers ('Non-streaming', billed per token) sharpen the purpose further.

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 practical routing guidance ('For a dedicated endpoint pass its `<project_slug>/<endpoint_slug>` as the model'), which is useful for choosing between a shared model and a dedicated endpoint. However, it never states when to use this tool versus alternatives or any exclusions, leaving that to inference.

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?

Adds genuine context beyond the annotations: the job is asynchronous, it runs over an uploaded file, and it bills at a discount to real-time inference. However, destructiveHint=true is never explained (does the job consume quota, hold the file, cost money up front?), and nothing is said about job state, failure modes, or how long results persist.

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?

Two compact sentences with the core action and the key constraint front-loaded. The trailing 'Together: POST /batches' is raw API trivia that adds little for an agent, a minor bit of 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?

For a 5-parameter creation tool with no output schema and only a destructiveHint annotation, the description omits important follow-up context: what the call returns (a batch id/object) and that status is retrieved via together_get_batch. Adequate for triggering the call, thin for using its result.

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 every parameter (endpoint, model_id, priority, input_file_id, completion_window) is already documented in the schema with its enum values. The description adds no syntax, format, or default guidance beyond that, so the 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 (Start) and resource (asynchronous batch job) plus the required input form (uploaded JSONL file, purpose batch-api). It is clearly distinguishable from siblings like together_get_batch and together_list_batches, though it never names them 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?

Gives a real prerequisite (a pre-uploaded JSONL file with purpose batch-api) and the motivating context (async, discounted vs real-time inference), which tells the agent when this tool is the right one. It stops short of stating alternatives or exclusions, e.g. that real-time use should go to together_chat_completion.

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?

Annotations supply destructiveHint=true, but the description contributes real behavioral value beyond them by disclosing that calls are billed per token (a cost side-effect) and mapping to the POST /embeddings endpoint. It still omits rate limits, auth requirements, and batching behavior. No contradiction with annotations, since it makes no claim about mutation.

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?

Two short sentences, front-loaded with the core action and the billing caveat. The endpoint mapping ('Together: POST /embeddings') earns its place for API alignment. Minimal 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?

For a simple two-parameter tool with full schema coverage, the description covers the essentials. However, with no output schema present it does not indicate what is returned (embedding vectors), and it omits model guidance, leaving modest gaps for an agent to fill.

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 both parameters are already documented, and the description adds only the 'one or more texts' scope for 'input'. It says nothing extra about model selection beyond what the schema example 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?

States a specific verb ('Generate') plus resource ('vector embeddings') and scope ('one or more texts'). The resource is unambiguous and separable from siblings such as together_chat_completion and together_generate_image without opening any schema.

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 when-to-use, when-not-to-use, or alternative guidance is given. The description never tells the agent which sibling to prefer (e.g. embeddings vs. chat completion) or what the prerequisites are.

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?

The annotation only carries destructiveHint=true, so the description does real work: it warns the endpoint STARTS AUTOMATICALLY and bills per minute of uptime until stopped. That is exactly the cost/behavioral fact an agent needs before invoking, and it does not contradict the annotation.

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 clauses, purpose front-loaded, the billing hazard emphasized, and the hardware-id pointer last. Nothing is redundant and there is 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?

For an 8-parameter creation tool with no output schema, the description covers cost behavior, the auto-start default, and the hardware lookup dependency. The one gap is that it never says what comes back (e.g. an endpoint id needed for later start/stop calls), which matters for a create-then-manage workflow.

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 already 88%, so the baseline is 3, but the description adds real meaning beyond the schema: inactive_timeout is framed as the auto-stop lever, hardware is tied to together_list_hardware for valid ids, and the automatic start is stated even though 'state' lives only in the schema.

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 ('Deploy a model on dedicated GPUs'), which separates it cleanly from together_start_endpoint, together_stop_endpoint, and together_list_endpoints. The 'POST /endpoints' note pins down the underlying resource so the agent knows exactly what is being created.

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 concrete routing guidance ('use together_list_hardware for valid hardware ids') and conditional advice ('set inactive_timeout to auto-stop it'), which tells the agent what to do before and after calling. It stops short of explicitly contrasting this with alternatives like start_endpoint or serverless chat_completion, so it is clear context rather than full when/when-not guidance.

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?

Annotations only carry destructiveHint=true, so the description's disclosure that the job is 'billed per token processed' adds genuine behavioral context an agent needs before invoking. It still omits what a 'destructive' create implies (resource consumption, irreversibility) and any auth/permission requirements.

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?

Four short clauses, purpose front-loaded, cost warning early, and the cancel pointer placed before the API-endpoint mapping. Efficient overall; the raw 'POST /fine-tunes' endpoint note is the only marginal element.

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 14-parameter mutation tool with no output schema, the description never mentions the return value (e.g. the job id that together_cancel_fine_tune would need) or validation-file expectations. Adequate on purpose and cost, thin on outcome and prerequisites for the more advanced 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 description coverage is 79%, so the schema already documents most of the 14 parameters (model, suffix, training_type, from_checkpoint, etc.). The description only implicitly signals the training_file requirement and adds no format or defaulting detail 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 and resource ('Start a fine-tuning job on an uploaded training file') and names the sibling that terminates it (together_cancel_fine_tune). An agent can distinguish this from together_get_fine_tune / together_list_fine_tunes immediately.

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?

Names the prerequisite (an already-uploaded training file) and points to the cancellation alternative, so the create/stop pair is unambiguous. It stops short of stating exclusions or when creation is inappropriate, but since no sibling also creates fine-tunes, the routing is clear.

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?

Annotations give only destructiveHint=true, so the description usefully discloses billing on a per-image/megapixel basis and the default small-response URL behavior with the base64 caveat. It still omits sync-vs-async behavior and whether the call blocks, keeping it short of a 5.

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, front-loaded with the core purpose, followed by cost and output-format facts. Every sentence carries distinct information and nothing is repeated from 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?

With no output schema, the description correctly states the default return shape (image URLs vs base64), and it covers cost. For a 12-parameter generation tool it is nearly complete, though it could note latency/blocking behavior or URL persistence.

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 83%, so the schema already documents nearly all 12 parameters. The description adds the default output behavior (URLs rather than base64, to keep responses small), which is useful but only marginally beyond what the response_format enum description already says.

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 ('Generate images from a prompt') and is unmistakably distinct from every sibling, none of which produce images. The mapping to the REST endpoint reinforces exactly what the tool does.

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?

It implies usage through the prompt framing but never states when to call this versus alternatives, nor when to prefer url over base64 output beyond noting the size trade-off. No preconditions, model-selection guidance, or exclusions are given.

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?

readOnlyHint=true already establishes the safety profile, so the description is free to add the valuable part: the full set of terminal and in-flight status values plus the conditional output_file_id / error_file_id fields, which tells the agent how to interpret a completed vs failed job. Missing only operational notes such as polling cadence or rate limits.

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 tightly packed sentence front-loads the verb, the return payload, and the status domain, followed by a short endpoint reference. No filler, and the most decision-relevant information comes first.

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?

With no output schema, the description properly compensates by naming the returned fields and the status enum, which is what an agent needs to branch on results. A brief note on polling behavior or the lifetime of expired/cancelled jobs would make it fully complete.

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% for the single batch_id parameter, so the baseline is 3. The description does not extend the meaning of batch_id (e.g. where to obtain it) beyond what the schema already states.

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 ("Fetch one batch job") and enumerates exactly what is returned (status, progress, output_file_id / error_file_id), which cleanly separates it from together_list_batches and together_create_batch. An agent can identify it without opening the schema.

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: the mention of status/progress/output_file_id makes it obvious this is the polling tool after create_batch, but the description never says when to use it instead of list_batches or what to do while status is VALIDATING/IN_PROGRESS. No explicit alternatives or exclusions are given.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the concrete set of fields returned and the underlying REST call, but says nothing about auth requirements, error behavior for an unknown id, or whether the response is cached/eventually consistent.

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?

Two compact sentences with the resource and returned fields front-loaded, then the REST mapping. No filler or redundancy.

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 carries the burden of telling the agent what comes back — and it does list the response fields. With one fully documented parameter and readOnlyHint covering safety, this is nearly complete, though response shape/nesting is only summarized.

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% for the single endpoint_id parameter, which the schema already documents with an example value. The description only restates the id via the path template GET /endpoints/{endpointId}, adding no new constraint. 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 (one dedicated endpoint), and enumerates the returned fields (state, model, hardware, autoscaling bounds, display name). This cleanly separates it from together_list_endpoints.

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 implied by the singular resource and the required endpoint_id, but the description never states when to prefer this over together_list_endpoints or the start/stop siblings, nor any prerequisite such as needing an existing endpoint id.

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?

The readOnlyHint annotation already establishes this is a safe read, so the description's job is lighter. It adds genuine value by disclosing the key return content, including processing_status and the validation_report that explains rejection, which an agent would not otherwise know exists. It omits auth/permission notes and any error behavior for unknown ids, keeping it short of a 5.

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 naming the resource and its notable fields, followed by the underlying REST endpoint. No filler or redundancy.

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 usefully names the two payload fields an agent most needs. For a simple get-by-id tool this is nearly complete; the only gap is that it doesn't describe the full metadata shape or failure modes.

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?

Only one parameter (file_id), and schema description coverage is 100% with an example ('file-abc123') already in the schema. The description adds nothing about the parameter, so the 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 and resource ('Fetch one file's metadata') and names the distinguishing payload fields (processing_status, validation_report). An agent can tell it apart from together_list_files and together_list_fine_tune_events without opening the schema.

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 implied: fetch a single file by id, notably to learn why a fine-tune training file was rejected. However, there is no explicit statement of when to prefer this over together_list_files or a fine-tune status call, and no prerequisites or exclusions are given.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real value by enumerating what the response contains, effectively compensating for the absent output schema. It does not mention behavior on an unknown or invalid id, which keeps it short of a 5.

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?

Two compact sentences: the payload contents are front-loaded and the API route is appended as a supplementary anchor. No filler or redundancy.

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 read tool, the description plus the fully documented schema covers what an agent needs, and the field enumeration substitutes for the missing output schema. Only error/not-found handling is left unaddressed.

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?

Only one parameter, documented in the schema with 100% coverage and a concrete example (ft-abc123). The description adds nothing about the id format beyond repeating the path template, 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 (one fine-tuning job) and enumerates the exact payload fields returned (status, progress, hyperparameters, token counts, cost, output model name). It is clearly distinguished from siblings like together_list_fine_tunes and together_list_fine_tune_events.

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 singular-object naming plus the referenced endpoint GET /fine-tunes/{id} imply this is the single-job lookup counterpart to list_fine_tunes, but the description never says when to use it over listing or event-listing tools, nor any prerequisites. Usage is inferable rather than stated.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description carries a lighter burden. It usefully discloses the shape of the returned records (status, progress, model, file ids), but says nothing about pagination, result limits, or ordering — meaningful gaps for a list endpoint.

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?

Two tightly packed sentences with no waste; the enumeration of returned fields comes before the API endpoint mapping, so the most useful information 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?

With no output schema, the description does the work of naming the key fields on returned batch records, which is enough for an agent to use the result. It falls short only on operational details like pagination and volume, which are not covered anywhere else.

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 per the baseline a 4 applies. There are no argument semantics to clarify, and the description correctly implies the call is unfiltered.

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 ('List batch inference jobs') and enumerates the notable fields returned (status, progress, model, file ids). It is clearly distinguishable from together_get_batch and together_list_fine_tunes, though it never names a sibling 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: the agent can infer this is the tool for enumerating existing batches rather than fetching one (together_get_batch) or creating one (together_create_batch). There is no explicit when-to-use statement, no exclusions, and no note about whether it returns all batches or a page.

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?

readOnlyHint=true already covers the safety profile. The description adds useful context beyond that: the returned fields, the full set of lifecycle states, and the cost implication (dedicated endpoints billed by the minute). It does not mention pagination or result limits, so it falls short of full behavioral disclosure.

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 with the core capability front-loaded; no filler. The trailing 'Together: GET /endpoints' is a mild redundancy of the name/title for a listing tool, but it is short enough not to hurt readability.

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 read-only list tool with no output schema, the description covers what is returned, the state vocabulary, and a practical filter scenario, while annotations carry the safety profile. An agent has everything needed to call it correctly.

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 would be 3, but the description earns extra credit by explaining the combined intent of mine=true plus type=dedicated (account ownership and minute-based billing), which the per-field schema text does not convey. usage_type is still only explained by the schema.

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 ('List endpoints') and even enumerates the fields returned (model, owner, state) with the possible state values. It is clearly a listing operation, but it never contrasts itself with the sibling get_endpoint for single-endpoint retrieval, so sibling differentiation is left implicit.

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 concrete guidance for a specific scenario: 'Use mine=true and type=dedicated to see what is running on your account and billing by the minute.' That tells the agent when the filter combination is appropriate, though it offers no explicit when-not or alternative tool 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?

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read. The description adds useful behavioral context — that status, parameters, and results appear only 'once completed' — and exposes the backing endpoint (GET /evaluation). However it omits pagination/ordering behavior despite the limit parameter, so value beyond annotations is modest.

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?

Two compact sentences, front-loaded with the resource and its contents, followed by the API reference. 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.

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

With no output schema, the description usefully characterizes what comes back (status, parameters, results once completed), which is enough for a 2-param, zero-required list tool. Minor gap: no pagination or result-ordering note to complement the limit parameter.

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 schema already documents constraints (limit 1-1000) and the full status vocabulary. The description adds nothing about either parameter, so the baseline of 3 for full schema coverage 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 (List) and resource (LLM-as-a-judge evaluation jobs), and parenthetically enumerates the evaluation types (classify, score, compare) plus what the response contains. This clearly separates it from sibling list tools such as list_batches, list_fine_tunes, and list_models.

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 implied by the verb and the tool name — use it to enumerate evaluation jobs — but there is no explicit guidance on when to prefer this over related reads, no mention of prerequisites, and no pointer to how to narrow results (e.g. by status). Implied-but-unstated usage lands at 3.

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?

Annotations already declare readOnlyHint=true, and the 'GET /files' note reinforces the read-only semantics. Beyond that the description adds the returned attribute set (size, type, purpose, validation status) but says nothing about auth requirements, pagination, or result limits, which is the sort of context that would raise this above the annotation baseline.

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?

Two tightly packed sentences, front-loaded with the resource scope and finishing with the returned fields plus the underlying endpoint. No filler and nothing buried.

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?

With no output schema, describing the returned attributes (size, type, purpose, validation status) is genuinely useful compensation, and the read-only annotation covers safety. The only gap is the absence of any pagination or ordering note for a list operation.

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 there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter semantics are needed or missing.

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+resource ('List uploaded data files') with the scope of file kinds (fine-tune, eval, batch-api inputs, job outputs) enumerated, and it lists the fields returned. This clearly distinguishes it from the other list_* siblings (batches, endpoints, models, fine-tunes), which an agent can rule out at a glance.

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 by the description of what is returned; there is no explicit when-to-use guidance, no exclusions, and no mention of the obvious alternative together_get_file for fetching a single file's details. Adequate for a simple zero-arg lister but leaves routing to inference.

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?

Annotations declare readOnlyHint=true, so the safe-read profile is covered. The description adds the useful diagnostic framing ('first place to look when a job failed') but doesn't describe ordering, pagination, retention, or how many events to expect. With annotations covering safety, a 3 reflects added context without rich behavioral disclosure.

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?

Two tight sentences plus an endpoint hint. The purpose and diagnostic framing are front-loaded, and every sentence earns its place with no redundancy.

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 read-only list tool with annotations covering safety and a fully documented single parameter, the description is nearly complete. It tells the agent what it returns (event types) and when to reach for it. Missing only return ordering/volume details, which is minor for a diagnostic event log.

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?

Only one parameter, and the schema fully documents it (100% coverage, e.g. 'ft-abc123'). The description adds the endpoint path context (GET /fine-tunes/{id}/events), which corroborates the parameter's role. Baseline for a 0-param tool is 4; here the single param is already well described, and the description doesn't add format detail beyond the schema.

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: 'List the event log of one fine-tuning job.' The parenthetical enumerates the actual event types (queued, started, checkpoint saved, epoch completed, errors), which makes the purpose concrete and distinguishable from siblings like together_get_fine_tune or together_list_fine_tunes.

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?

Explicitly gives a strong usage context: 'The first place to look when a job failed.' That's a clear when-to-use signal for a diagnostic scenario. It doesn't name an alternative tool or state when-not-to-use, which keeps it short of a 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?

readOnlyHint=true already establishes the safety profile, so the bar is lower. The description usefully adds what is returned per job, but says nothing about pagination, result limits, or whether the list is scoped to the caller's account — meaningful gaps for a list endpoint.

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?

Two sentences, no filler, with the field inventory front-loaded and the API mapping condensed into a trailing clause. Every element earns its place.

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?

With no output schema, the description carries the burden of describing the return payload, and it does so by naming the four key fields. It stops short of noting pagination or result ordering, which would matter for an agent consuming a long job list.

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 and schema coverage is 100%, so the baseline of 4 applies per the rubric. There is nothing parameter-related the description needed to compensate for.

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 ("List fine-tuning jobs") and enumerates the fields surfaced (status, base model, output model name, training settings). It is clearly distinct from together_get_fine_tune in intent, but the description never explicitly names a sibling, so differentiation still depends on the reader inferring singular-vs-list semantics.

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 browse-everything call versus together_get_fine_tune for one job, but there is no explicit when-to-use/when-not guidance or mention of alternatives such as together_list_fine_tune_events. Adequate but leaves routing to inference.

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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral context beyond that: the price unit (cents per minute), the availability semantics when a model is supplied, and the underlying REST mapping (GET /hardware). It does not cover pagination or result size, keeping it at a 4.

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, each earning its place: what is listed, what the optional param does, and the API endpoint mapping. The scoping constraint is front-loaded and there is 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?

With no output schema and a single optional parameter, the description compensates well by naming the fields returned and the availability behavior. Minor gaps remain around ordering or throttling, but nothing essential for correct invocation is missing.

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 schema already states the model parameter filters to compatible hardware with availability. The description restates the same behavior, adding no syntax or format detail 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 and resource ('List hardware configurations for dedicated endpoints') and enumerates the returned fields (GPU type/count/memory, price in cents per minute). This is clearly separable from siblings like list_models or list_endpoints without opening any schema.

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?

Explicitly says to pass a model to narrow results to compatible configurations with live availability, giving the agent a clear conditional usage rule. It stops short of naming an alternative tool or stating when not to use it, so it is strong but not exhaustive.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower; the description adds genuine value by disclosing the returned fields (type, context length, org, license, per-token pricing) since no output schema exists. It says nothing about pagination, result size, or how the optional dedicated filter changes the response.

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 the verb and return payload in one dense sentence. The trailing 'Together: GET /models.' is an API mapping that adds little for an agent, but it costs only a few tokens.

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?

With no output schema, the description compensates by enumerating the returned fields, which is the key completeness gap for a listing tool. Missing only secondary details like pagination or result ordering.

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?

Only one optional parameter and schema description coverage is 100%, so the schema already explains the dedicated filter fully; baseline 3 applies. The description's list of model types does not correspond to any parameter and adds no filtering syntax.

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+resource ("List Together's models") plus an enumeration of the fields returned (type, context length, organization, license, pricing), so the agent knows exactly what this surface provides. It doesn't explicitly differentiate from the many other together_list_* siblings, but the resource is unambiguous on its own.

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 statement of when to call this versus alternatives, nor any prerequisite or sequencing guidance (e.g. 'call before chat_completion to pick a model'). The use case is only implied by the resource name.

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?

Annotations supply only a title and destructiveHint, so the description carries most of the burden and does add real value: per-minute billing until stopped, reversibility via the stop tool, and the underlying REST call (PATCH /endpoints/{endpointId} with state=STARTED). It omits auth/permission requirements and whether the start is synchronous, so not a 5.

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, zero filler, with the core action front-loaded and the cost/reversibility/API details ordered by usefulness to an agent.

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 one-parameter start tool with full schema coverage and no output schema, the description covers action, cost implication, reversibility, and the concrete API semantics. Nothing an agent needs in order to invoke it correctly is missing.

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% for the single endpoint_id parameter, so the schema already documents it. The description only echoes it implicitly through the path template, adding nothing new; baseline 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?

States a specific verb and resource ('Start a stopped dedicated endpoint') and immediately distinguishes itself from the sibling it unwinds, together_stop_endpoint. An agent can tell start from stop without opening either schema.

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?

Implies the applicability condition ('a stopped dedicated endpoint') and names the reversing alternative, together_stop_endpoint. It stops short of stating explicit exclusions (e.g. what happens if the endpoint is already running), so it is clear context rather than full when/when-not guidance.

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?

Annotations only supply destructiveHint=true; the description adds real behavioral context — billing stops, in-flight/future requests fail, and the state is recoverable via restart. It also discloses the underlying REST semantics (PATCH with state=STOPPED), which helps the agent predict idempotent behavior. It doesn't cover data retention or propagation timing.

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, then consequences, then API mapping. No filler, and each sentence adds a distinct fact.

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 one-parameter, no-output-schema mutation tool this is nearly complete: the agent knows the effect, the reversibility, and the failure mode of dependent calls. Minor gaps remain around whether stopping is immediate/synchronous and what the response looks like, but these are low-risk for a hint about a rich API.

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% for the single endpoint_id parameter, so the schema already carries the semantics. The description only echoes the id via the REST path notation, adding no new parameter meaning. 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 and resource: 'Stop a running dedicated endpoint.' Combined with the title and the sibling set, an agent can immediately distinguish this from together_start_endpoint, together_create_endpoint, or together_get_endpoint.

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 clear condition for use (to stop per-minute billing) and states the operational consequence that requests fail until restarted, which implicitly points to together_start_endpoint as the reverse action. It stops short of explicitly naming the restart tool as the 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description goes beyond that by disclosing what is returned (organization, project, slug) and why the slug matters, though it says nothing about auth requirements or failure behavior.

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, front-loaded with the core identity resolution before the explanatory note about the slug and the usage hint. 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?

For a zero-parameter, read-only identity tool with no output schema, the description covers what is returned, why it matters, and when it is useful. Nothing an agent needs to invoke it correctly is missing.

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 and schema coverage is 100%, so there is nothing for the description to disambiguate. The baseline of 4 for a parameterless tool 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?

States a specific verb (Identify) and resource (the API key), then enumerates exactly what is resolved: organization, project, and project slug. This is clearly distinguishable from the sibling inference/batch/endpoint-management 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?

Provides concrete usage context ('a cheap way to confirm the key works') and explains the downstream relevance of the slug for dedicated-endpoint model naming. It doesn't name alternatives, but no real alternative exists among the siblings, so context is clear.

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