Server Quality Checklist

Tool Scores

• get_product_infoA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral burden. It does disclose the important auth behavior ('No API key required') and 'Get' reasonably implies a read-only operation. It does not describe what the returned object looks like, whether the content is static, or if any limits apply, but for a lightweight info tool this is acceptable.

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

  Conciseness5/5

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

  A single sentence encapsulates the tool's purpose, scope, and a key auth constraint. Every element earns its place, and the most relevant information is front-loaded with the verb and resource first.

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

  Completeness4/5

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

  For a tool with one optional parameter, 100% schema coverage, and no output schema, the description is essentially complete for invocation. The only notable omission is an explicit note about what form the returned information takes, or guidance to use get_api_docs for API-specific needs, but these are minor for a simple 'get info' utility.

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

  Parameters3/5

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

  The input schema already provides 100% coverage with an enum and a clear description for the single optional 'topic' parameter. The description mostly repeats the same topic list and adds no deeper meaning about parameter syntax, defaults, or interactions, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description names a specific verb ('Get information about'), defines the singular resource ('Scriptivox capabilities'), and enumerates the covered domains: transcription, audio, video, subtitles, meeting bot, API. It is clearly distinguished from siblings like get_pricing or get_supported_languages by focusing on capabilities rather than prices, languages, or API docs.

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

  Usage Guidelines3/5

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

  The intended use is implied: call this when you need general information about Scriptivox capabilities. However, it does not explicitly say when to prefer a sibling such as get_api_docs for API-specific documentation or get_pricing for pricing, and the 'API' topic could overlap with get_api_docs, so the routing guidance is only implicit.

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

• transcribe_statusA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral burden. It adds the auth prerequisite ('Requires a configured API key') and clearly frames the tool as a status-checking operation. Still, it does not explain whether repeated checks are safe, what response format to expect, or whether it creates no side effects beyond what the name implies.

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

  Conciseness5/5

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

  The description is two concise sentences with no filler. The main purpose is front-loaded, followed directly by relevant usage conditions and a required prerequisite. Every sentence earns its place.

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

  Completeness3/5

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

  For a one-parameter status-checking tool, the description is adequate for selection and basic invocation. However, there is no original output schema and no return-format guidance, and the description does not clarify how the result is returned or how to interpret statuses. The sibling overlap with transcription_status also leaves some contextual ambiguity.

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

  Parameters3/5

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

  The input schema already fully documents the only parameter, transcribing 'transcription_id', including where it comes from. The description adds no extra parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the verb and resource: 'Check the status of a Scriptivox transcription job.' It is specific enough for normal use. However, the sibling list includes transcription_status, which may serve the same role, and the description does not distinguish between them.

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

  Usage Guidelines4/5

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

  The description gives explicit usage scenarios: long-running transcriptions, after a timeout, and verifying completion. It also notes the API key requirement. It does not mention alternatives or explicitly say when not to use it, so it falls just 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.

• transcription_statusA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It discloses comparing with transcribe_status but never explains what the actual behavior is—such as what a status check returns, whether it is read-only, or if it can return not-found states. The deprecation and removal version are useful metadata, but they do not substitute for describing the operation's runtime behavior.

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

  Conciseness5/5

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

  The description is concise and front-loaded: the deprecation warning and replacement tool appear first, followed by the compatibility scope and removal version. Every sentence carries a distinct piece of information, with zero redundant phrases.

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

  Completeness3/5

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

  This is a very simple deprecated alias with one parameter and no output schema, so the description does not need to explain complex return formats. However, because it says behavior is 'identical to transcribe_status' and does not describe that behavior, an agent that cannot read the sibling description would remain under-informed. It is sufficient for routing but not for understanding the tool's own contract.

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

  Parameters3/5

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

  The schema provides 100% coverage for the single parameter transcription_id with the description 'The transcription ID.' The tool description adds no extra param semantic context, such as required format, source, or relationship to existing transcriptions, so it remains at the baseline without requiring special compensation.

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

  Purpose4/5

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

  The description clearly identifies this tool as a deprecated alias for transcribe_status, contrasting it directly with its replacement sibling. It does not explicitly state the underlying operation (e.g., 'retrieves a transcription status'), but the tool name and 'Identical behavior to transcribe_status' make the resource unambiguous. It distinguishes itself from transcribe_status by specifying the deprecation and removal timeline.

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

  Usage Guidelines5/5

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

  Explicitly instructs the agent to use transcribe_status instead: 'use transcribe_status instead.' It also provides context that this is only for backward compatibility with a specific package version and will be removed in 2.0.0, so the agent knows not to select this tool for new workflows.

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

• check_balanceA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. 'Check' strongly implies a non-destructive read, and 'Requires a configured API key' reveals the authentication expectation. It does not describe the response format or rate limits, but for a zero-parameter check this is reasonably transparent.

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

  Conciseness5/5

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

  The description is two short sentences with no filler or redundant detail. The primary purpose is front-loaded, followed immediately by the operational prerequisite. Each phrase contributes distinct information, making it easy for an agent to parse.

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

  Completeness4/5

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

  For a parameterless read operation with no output schema, the description is largely complete: it states what is checked and what is required. The only real gap is not clarifying the relationship with the sibling get_pricing, which the overlapping 'pricing' term makes somewhat ambiguous.

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

  Parameters4/5

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

  The tool has zero parameters and 100% schema description coverage, so there is no input ambiguity. The description adds value by clarifying what data is returned: credit balance, available hours, and pricing. This matches the baseline for parameterless tools and provides useful semantics beyond the empty schema.

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

  Purpose4/5

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

  The description names a concrete verb ('check') and precise resources: Script API credit balance, available hours, and pricing. It is clearly a read-operation tool. It loses the top score because 'pricing' likely overlaps with the sibling get_pricing, and the description does not differentiate them.

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

  Usage Guidelines3/5

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

  The description supplies one practical prerequisite: a configured API key. That gives some context about when the operation is executable. It does not explicitly state when to prefer this tool over get_pricing or other information tools, so selection among alternatives is left to inference.

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

• export_transcriptA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses important preconditions: transcript must be `completed` and an API key must be configured. It does not describe the exact response shape, error behavior, or whether the operation affects billing, but it does make the tool's read-oriented export behavior clear.

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

  Conciseness5/5

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

  The description is compact and front-loaded. Two sentences cover the action, formats, supported options, and two critical preconditions, with no filler or redundant restatement.

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

  Completeness4/5

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

  For a tool with eight parameters, all parameters are documented in the schema, and the description covers the preconditions and output formats. The main gap is that there is no mention of the exact successful response content, but for an export tool the response type is largely implied by the format choices.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameter semantics are already fully documented. The description groups the parameters as "segmentation knobs" but adds little beyond what the schema provides. This matches the baseline for high schema coverage.

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

  Purpose5/5

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

  The description clearly states a specific action ("Export"), a specific resource ("Scriptivox transcript"), and the exact output formats (SRT, WebVTT, plain text). It also adds the "completed" status requirement, which separates it from transcription creation and status-checking sibling tools.

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

  Usage Guidelines4/5

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

  The description explicitly says this tool requires a transcript in `completed` status and a configured API key, giving an agent actionable preconditions for correct use. It does not explicitly name alternative tools or say when not to use it, but the only export tool in the sibling set is clearly scoped by these requirements.

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

• get_api_docsA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that no API key is required, which is useful auth-relevant context, and the 'Get' wording implies a read-only operation. However, it does not describe the return format, pagination, or any other behavioral detail beyond that.

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

  Conciseness5/5

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

  The description is two short, front-loaded sentences. The first states the purpose and the second lists the available sections and calls out the auth requirement. No filler or redundancy is present.

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

  Completeness5/5

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

  For a simple read-only documentation tool with one optional parameter fully described by the schema, the description is sufficient. It covers the resource, the sections, the credential requirement, and is complete enough for an agent to invoke the tool correctly without additional context.

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

  Parameters3/5

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

  Schema description coverage is 100% and the section parameter is fully documented there, including the default value and enum values. The description repeats most enum options but adds little semantic meaning beyond the schema. This matches the baseline of 3 for tools whose schema carries the parameter documentation load.

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

  Purpose5/5

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

  The description names the exact resource: "Scriptivox API documentation," and enumerates the available sections. This sets it apart from the sibling get_* tools, which target pricing, supported languages, product info, or check_balance. No ambiguity remains about 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.

  Usage Guidelines4/5

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

  The description clearly communicates this is the tool for retrieving Scriptivox API documentation, with the relevant documentation sections listed. It does not explicitly contrast it with sibling tools or state when not to use it, but the resource distinction is strong enough that an agent can pick it correctly.

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

• transcribe_cancelA
  4.2/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so well: it explains idempotency, the balance-release side effect, the 409 behavior for terminal jobs, and the API key requirement. These are all meaningful behavioral facts beyond what the schema exposes.

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

  Conciseness5/5

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

  Four short sentences, each adding a distinct fact: operation, side-effect, idempotency, failure behavior, and required auth. No fluff or redundancy.

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

  Completeness4/5

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

  For a simple one-parameter operation, the description covers what happens on success, a key error condition, and the auth requirement. It doesn't describe the success response payload, but with no output schema, this is a minor gap and none of the essential invocation details have a hole.

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

  Parameters3/5

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

  The single parameter transcription_id is already fully described in the schema as a UUID, so description-level add-on is unnecessary. The description does not add further semantic guidance, which is fine given 100% schema coverage and one parameter.

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

  Purpose5/5

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

  The description states a specific action, 'Cancel an in-flight Scriptivox transcription', and the resource state it applies to. It also adds the effect of releasing reserved balance, which differentiates it from terminal/cleanup operations like transcribe_delete.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool through 'in-flight' and notes that 'already-terminal jobs' return 409 CONFLICT. However, it does not explicitly name alternative tools, such as checking status before canceling or using transcribe_delete for completed jobs, so the guidance is implied rather than fully explicit.

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

• get_supported_languagesA
  4.3/5.0
  Behavior4/5

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

  No annotations are present, so the description bears the full behavioral burden. It discloses that this is a list operation, what information is returned (language names and ISO codes), and that no API key is required. For a simple read-only tool without side effects or rate-limit notes, this is sufficient, though it doesn't comment on pagination or response structure.

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

  Conciseness5/5

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

  Two short sentences deliver the purpose, scope, return format, and auth requirement with zero redundancy or filler. All information is front-loaded and necessary.

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

  Completeness5/5

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

  For a zero-parameter, schema-less, output-schema-less tool, the description covers everything an agent needs: what resource is listed, what content type it returns, and the authentication context. Nothing material is missing.

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

  Parameters4/5

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

  The input schema is empty (0 parameters), so the baseline is 4 per the rubric. The description correctly doesn't introduce any parameters and adds only a non-parameter note about API key requirements, which is helpful context.

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

  Purpose5/5

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

  The description states the exact verb 'List' and resource 'all languages supported by Scriptivox for audio/video transcription,' and adds that it returns names and ISO codes. This is specific and distinct from sibling tools like pricing, product info, or transcription operations.

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

  Usage Guidelines3/5

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

  Usage is implied: if you need to know which languages are supported, use this tool. However, there is no explicit guidance on when to use it vs alternatives, nor any exclusion statements beyond the 'No API key required' note. It is adequate but not instructional.

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

• list_transcriptionsA
  4.4/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the full burden. It discloses that responses omit the full transcript body and that authentication/config is required. For a list operation, this conveys the non-destructive read behavior and the key output limitation, though it does not describe potential errors, rate limits, or exact return shape beyond what the schema already implies.

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

  Conciseness5/5

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

  Three sentences with no filler. The core capability is front-loaded, the key scoping constraint (omitted body) comes second, and the auth prerequisite is last. Every sentence earns its place.

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

  Completeness4/5

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

  Given no annotations and no output schema, the description does most of the heavy lifting: it explains pagination, filtering, auth requirement, and how to get full transcript data. It could be more explicit about the exact response shape, but the guidance is sufficient for an agent to correctly call the tool, navigate pagination, and route follow-up requests to transcribe_status.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already thoroughly documents parameters like to, from, limit, order, cursor, and status. The description adds a high-level grouping ('optional status/date filters and cursor pagination') but no parameter-level meaning beyond what the schema provides, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description states a clear verb and resource: 'List recent transcriptions for the configured API key'. It also distinguishes itself from a sibling by noting the full transcript body is omitted and one should 'fetch transcribe_status per id to read it', so an agent can tell this listing operation apart from the status/individual-fetch tools without opening schemas.

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

  Usage Guidelines5/5

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

  It not only says what the tool does, but also gives an explicit conditional for an alternative: when you need the full transcript body, use transcribe_status per id. The prerequisite 'Requires a configured API key' is also stated, which helps an agent decide whether this tool is usable in its current environment.

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

• transcribe_deleteA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden, and it does well: it discloses idempotency, soft-delete semantics, a 409 CONFLICT failure mode, and the API key requirement. It does not state the successful response shape or whether the soft-delete can be undone, but the disclosed behaviors are materially helpful and far beyond a minimal mutation description.

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

  Conciseness5/5

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

  The description contains four short, high-value statements in a rational order: the action, its idempotency, its key conflict behavior with a workaround, and its authentication requirement. There is no repeated information from the schema and no filler.

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

  Completeness4/5

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

  For a simple one-parameter delete tool with no annotations, the description covers the action, idempotency, the important conflict case, and auth. It does not describe success-path return codes, but the 409 handling plus cancel workflow is squarely the most job-relevant context an agent needs before calling the tool.

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

  Parameters3/5

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

  Schema coverage is 100%: the only parameter, transcription_id, is already described as a UUID transcription ID. The description adds no new meaning beyond associating that ID with the transcription record, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Soft-delete a Scriptivox transcription record.' It clearly distinguishes this from the sibling cancel operation by framing cancel as a prerequisite for deleting in-flight jobs, so an agent can tell transcribe_delete apart from transcribe_cancel 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.

  Usage Guidelines5/5

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

  The description provides an explicit workflow condition: if the job is still in-flight, cancel first via transcribe_cancel. This directly tells the agent when it may use delete and what alternative to use instead, which is exactly the kind of routing guidance this dimension rewards.

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

• transcribe_uploadA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: local upload, internally driven 3-step flow, file size limit, and API key requirement. It does not mention return behavior or cost/consumption side effects, but for a transcription upload tool the key operational traits are covered.

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

  Conciseness5/5

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

  Three concise sentences with no filler. The core purpose is front-loaded, followed by the decisive usage condition and essential requirements. Every sentence earns its place.

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

  Completeness4/5

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

  For an 8-parameter tool with no output schema or annotations, the description gives a strong high-level context: local input, automatic upload flow, sibling alternative, and key constraints. It does not describe the returned result or polling behavior, but those are at least partially covered by parameter descriptions and the sibling ecosystem.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameters are already well documented. The description adds little new parameter-level meaning beyond noting that this tool shares the same options as transcribe_url, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the specific action: transcribe a LOCAL file by uploading it to Scriptivox. It is immediately distinguishable from the sibling transcribe_url by explicitly scoping to local files and contrasting with public-URL usage.

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

  Usage Guidelines5/5

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

  Gives an explicit usage condition: 'Use when the file isn't on a public URL.' It also points to transcribe_url as the related alternative and states prerequisites such as a configured API key and the 5 GB size limit.

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

• get_pricingA
  4.5/5.0
  Behavior4/5

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

  With no annotations present, the description carries the full burden of disclosing behavior. It does so by stating that no API key is required, which is a meaningful auth/invocation detail, and by enumerating what will be returned (plans, pay-as-you-go rates, signup URLs). It does not mention return format or caching, but for a simple no-parameter information tool, the key behavioral facts are communicated.

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

  Conciseness5/5

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

  Two sentences with no filler. The main purpose is front-loaded, the contents are itemized, and the final sentence adds the authentication note. Every clause earns its place.

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

  Completeness5/5

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

  For a zero-parameter, no-schema, informational tool, the description covers all an agent needs: what info is returned (subscription plans, pay-as-you-go rates), what is included (signup URLs), and whether auth is required (no API key). No critical context is missing.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema is empty, so parameter-level documentation is unnecessary. Baseline for 0 parameters is 4, and the description appropriately focuses on what the tool returns rather than on parameters that do not exist.

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

  Purpose5/5

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

  The description states a specific verb and resource ('Get Scriptivox pricing information') and enumerates the specific contents (subscription plans, API rates, signup URLs). This distinguishes it clearly from sibling tools like get_product_info and get_api_docs, which target different kinds of information.

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

  Usage Guidelines4/5

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

  The description makes the use case obvious: retrieving pricing details for Scriptivox. It also adds a practical usage context with 'No API key required', signaling the tool is accessible without authentication. It does not explicitly state when not to use this tool or give alternatives, but for a zero-parameter, read-only info tool, this level of guidance is adequate.

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

• transcribe_urlA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It covers key behavioral traits: auto-detection failure modes, the requirement for a configured API key, and the fact that diarize true forces alignment on regardless of `align`. This adds context beyond the schema, though it could have disclosed more about polling behavior or webhook details—mostly covered by schema, but not explicit here.

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

  Conciseness4/5

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

  The description is a single focused paragraph. It front-loads the core action and capabilities, then introduces the RECOMMENDED language hint and the API key note. Every sentence earns its place. A light structure (bullets) would improve skimmability, but the length is appropriate and not bloated.

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

  Completeness4/5

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

  There is no output schema, and no annotation safety metadata, so the description must do more work. It covers the keys: the URL format, language auto-detection risk, the API key requirement, and the interaction of align/diarize. Some gaps remain: what the transcription output looks like, when to use transcribe_upload, and webhook signature behavior are not detailed, but for a tool whose schema covers most parameter logic, this is quite complete.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds value by recommending the `language` parameter and explaining why explicit language guesses improve reliability, which the schema does not. It highlights the interaction between `diarize` and `align`. This extra context nudges the score up.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Transcribe audio or video from a public URL using Scriptivox AI.' It lists concrete capabilities (119 languages, speaker diarization, word-level timestamps) and distinguishes the tool from sibling transcribe_upload, which handles uploads rather than public URLs. An agent can clearly identify what this tool does and when to reach for it.

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

  Usage Guidelines5/5

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

  The description gives explicit, actionable usage guidance: always pass `language` when known, because auto-detection fails on short clips or code-switched audio. It also states a prerequisite (requires a configured API key). Although it does not name sibling alternatives, the when-to-use and when-to-avoid guidance for this specific tool is sufficient for correct invocation.

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

• transcription_urlA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden. It discloses that the tool is a deprecated alias with the exact behavior of transcribe_url and a finite lifecycle, which is the core behavioral context needed. It does not spell out the actual behavior itself, but that is intentionally delegated to transcribe_url.

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

  Conciseness5/5

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

  The description is very short and immediately front-loads the only action an agent should take: don't use this, use transcribe_url. Every sentence earns its place—deprecation, backward compatibility, removal, and identical behavior.

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

  Completeness5/5

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

  For a deprecated alias, the description is complete: it warns the agent, names the replacement, gives compatibility context, and clarifies behavior is inherent to the sibling. The rich input schema covers all parameters, and there is no output schema to describe.

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

  Parameters3/5

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

  Schema coverage is 100% for all 8 parameters, so the schema already documents every parameter. The description adds no parameter-specific meaning, which is acceptable here because it refers the agent to transcribe_url for behavior details.

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

  Purpose5/5

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

  The description explicitly labels the tool as a deprecated alias and states its behavior is identical to transcribe_url. This clearly identifies the tool's role and points to the appropriate sibling, making it separate from the other URL or status tools.

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

  Usage Guidelines5/5

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

  The description explicitly instructs 'use transcribe_url instead', warns of removal in 2.0.0, and notes the tool only exists for backward compatibility. An agent gets direct and unambiguous selection guidance.

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