OpenQR

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the creation action and a limit of 200 codes, but omits details such as error handling on exceeding the limit, atomicity, response format, or whether the operation is synchronous. This is adequate but not thorough.

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

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

The description is extremely concise with two sentences, no wasted words, and front-loaded with the core action. It efficiently conveys the essential purpose and a key requirement.

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 bulk creation tool with no output schema and moderate complexity, the description is too sparse. It fails to explain what happens on success (e.g., response includes created codes), how partial failures are handled, or if the operation is synchronous. The sibling tool 'create_dynamic_qr' may provide some context, but the description should be more self-contained.

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% (both parameters have descriptions in the schema). The tool description does not add any additional meaning beyond what the schema already provides. The mention of 'up to 200' is a constraint on the array, not a parameter attribute, and is not part of 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?

The description clearly states the action ('Create'), the resource ('dynamic QR codes'), and the key differentiator ('up to 200 at once'), which distinguishes it from the sibling tool 'create_dynamic_qr' that creates a single code. The API key requirement adds necessary context.

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 provides a prerequisite ('Requires an OpenQR API key'), which is useful for usage. However, it does not explicitly state when to use this tool over its single-code sibling or indicate any exclusions or context where it should not be used.

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

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

No annotations are provided, so the description carries the full burden. It clearly states the destructive effect (subdomain stops resolving), the non-destructive effect on existing codes (stay live), and the change of ownership (name becomes claimable). It does not mention idempotency or error behavior (e.g., what if subdomain already released), but for a tool with zero parameters, 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.

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

The description is three sentences long, each sentence adds essential information: action, effect on existing codes, ownership implication. No filler, no repetition. 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?

Given the tool has no parameters, no output schema, and annotations are absent, this description is sufficient. It tells the agent what the tool does, what the side effects are, and what is needed. The agent can confidently select and invoke this tool without ambiguity.

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 input schema has no parameters, so there is nothing to document. Baseline is 4, but since there are no parameters, no additional value can be added. The description is clear about what is being released, which compensates slightly. Score 3 because there is no parameter documentation needed but the description is still adequate.

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

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

The description clearly states the action ('Release the branded subdomain'), specifies the resource (subdomain), and distinguishes from siblings by noting that other tools like 'set_subdomain' or 'get_subdomain' exist. It precisely describes the effect: codes stay live on the plain short link, only the branded form stops resolving.

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 explicitly states when to use: when you want to release a branded subdomain. It also clarifies what happens—codes remain live on the plain link, the name becomes claimable—and notes the requirement of an OpenQR API key. No sibling tool does exactly this; 'set_subdomain' would be for assigning one. The description is complete 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?

No annotations are provided, so the description must disclose all behavioral traits. It only mentions creation and editability, but omits side effects (e.g., what is created/stored), return value format, potential failures, or rate limits. This is insufficient for safe invocation.

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

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

The description is extremely concise: two sentences that front-load the core purpose and a critical prerequisite. There is no unnecessary text, and every sentence adds value.

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?

Despite having only 3 simple parameters and no output schema, the description does not mention what the tool returns (e.g., a QR code ID or image URL) or any limitations. An agent would lack core context about the invocation outcome, making the description incomplete.

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

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

Schema description coverage is 100%, so the schema already documents parameters adequately. The description adds no additional context for parameters such as format, constraints, or usage examples, so it remains at the 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?

The description clearly states the tool creates a dynamic QR code with editable destination, distinguishing it from static QR codes and siblings like 'generate_qr'. The verb 'create' and resource 'dynamic QR code' are explicit.

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 implies when to use it (when editability is needed) by contrasting with 'later without reprinting'. It also notes the API key requirement. However, it does not explicitly mention when not to use it (e.g., for non-editable codes use generate_qr) or compare to bulk_create_dynamic_qr.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It discloses that an API key is required, but omits critical details such as whether the operation is idempotent, what happens if the folder already exists, or the return value. For a mutation tool, this is insufficient.

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

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

The description is one sentence, which is concise. However, it is overly brief, missing essential details. It does not front-load the most critical information beyond the basic purpose. The sentence earns its place but leaves significant gaps.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It explains the purpose and a prerequisite, but does not cover what the folder is used for, how it relates to codes, error behavior, or what happens after creation. More context is needed for effective use.

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 0%, and the description adds no meaning to the single parameter 'name'. It does not specify format, constraints, or examples. The description fails to compensate for the lack of schema documentation.

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

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

The description clearly states the verb ('Create') and resource ('a folder') with a specific purpose ('to organise codes'). It distinguishes from sibling tools like delete_folder and list_folders by being the create operation, though it does not explicitly differentiate from other create tools (e.g., create_dynamic_qr).

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 provides no guidance on when to use this tool versus alternatives (e.g., when to use list_folders instead). It only mentions an API key requirement, which is a prerequisite, not a decision criterion.

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

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

With no annotations, the description carries the behavioral burden. It discloses that aliases resolve to dynamic codes without changing the QR slug, that counts are separated, that free accounts have zero alias allowance (Pro has 10), and that an OpenQR API key is required. This is substantial, though it does not describe failure behavior when the allowance is exceeded.

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 sentences deliver purpose, use case, quotas, and authentication with no filler. The most important information is front-loaded in the first sentence.

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 mutating tool with no annotations and no output schema, the description covers the essential context: what the alias does, why to use it, quota limits, and auth requirement. It does not mention error/response behavior, but the schema covers parameter-level invocation details.

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 schema already documents id and slug thoroughly, including syntax and optionality. The description adds use-case context but no parameter-specific meaning beyond what the schema provides.

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

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

The description opens with a specific verb and resource: 'Create an extra short link (link alias) that resolves where one of your dynamic codes points.' It distinguishes the tool from create_dynamic_qr by explaining that the alias is an additional slug while the QR keeps its own slug, so scans and clicks are counted separately.

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 a clear use case: sharing a different slug per channel while preserving the QR's slug for separate counting. It does not explicitly name alternatives or state when not to use the tool, so it falls 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?

With no annotations, the description carries the full disclosure burden. It reveals that the code is saved to the library, is permanent, yields no analytics, requires an OpenQR API key, and returns a payload meant for generate_qr. This is a clear, honest picture of side effects and constraints, with no contradictions.

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 compact sentences, each with a distinct job: purpose, static-code implications, and next-step/API-key requirement. The information is front-loaded and every clause contributes, with no filler.

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

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

Covers the essential operational details an agent needs: supported types, static-vs-dynamic tradeoff, library persistence, API key requirement, and the rendering step via generate_qr. The only notable absence is a description of the exact payload structure, but the tool's dependence on generate_qr and the full schema descriptions mitigate that gap.

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

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

Schema description coverage is 100%, so the schema already documents type, label, theme, and the type-dependent fields object. The description only compresses the type list ('wifi, contact, vCard, email, SMS...') and adds no semantic detail beyond what the schema supplies, so it meets the baseline but does not exceed it.

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 'Save a static QR code to your library from structured fields' with a specific verb, resource, and list of supported payload types (wifi, vCard, email, SMS, etc.). The phrase 'Static codes bake the content into the code itself — no short link, no scan analytics, not editable later' clearly separates it from dynamic QR siblings, so the tool's identity and boundary are unambiguous.

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?

Explains that static codes embed content, lack scan analytics, and cannot be edited later, which tells an agent to prefer this tool when a permanent, self-contained QR is needed and to prefer dynamic tools when mutable URLs or analytics are required. It also directs the agent to 'Render the returned payload with generate_qr' and notes the API key prerequisite. It doesn't explicitly name an alternative tool, but the behavioral contrast with dynamic QR tools is strong.

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?

Without annotations, the description carries full behavioral burden. It discloses the API key requirement and the reusable nature of the theme, but omits success/failure behavior, idempotency (does it overwrite existing themes?), and possible side effects. Provides moderate transparency.

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 with zero waste. The first sentence states the purpose ('Save a reusable style theme'), and the second elaborates on the style parameter and a key requirement. Front-loaded and efficient.

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 2-parameter tool with no output schema, the description covers the style parameter detail and API key requirement but leaves notable gaps: no mention of what the theme is used for (QR generation?), whether names must be unique, or what response the tool returns. Adequate but not 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?

The schema has 50% coverage (only style has a description). The description adds specific field examples (fgColor, bgColor, dotType, cornerSquareType) that are not in the schema, adding meaning beyond structured data. However, the 'name' parameter still lacks guidance on uniqueness or format constraints.

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

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

The description clearly states the verb ('Save') and resource ('reusable style theme'), distinguishing it from sibling tools like delete_theme and list_themes. However, it does not explicitly differentiate from create_dynamic_qr, which also involves style configuration.

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 only usage guidance is the prerequisite 'Requires an OpenQR API key.' It lacks context on when to create a theme versus using inline styles in create_dynamic_qr, or when to reuse existing themes. No alternatives or exclusions are mentioned.

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

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

With no annotations provided, the description carries full burden. It transparently states that the deletion is permanent and the short link stops working, which are critical behavioral traits. However, it omits other potential behaviors, such as whether the deletion cascades to dependent resources, or if it requires specific permissions beyond the API key.

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

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

The description is extremely concise at two sentences, each earning its place: the first states the action and consequence, the second provides a crucial prerequisite. No unnecessary words.

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 delete operation with a single required parameter and no output schema, the description is largely complete. It covers the action, consequence, and key prerequisite. The only minor gap is the lack of explicit statement about irreversibility, which is implied by 'permanently delete.'

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 parameter 'id', which has a brief schema description ('The dynamic code id.'). The tool description does not add further detail about the id format, source, or validation rules. Since the schema already provides adequate meaning, a baseline of 3 is appropriate.

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

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

The description clearly states the action ('permanently delete'), the resource ('dynamic QR code'), and the consequence ('short link stops working'). This distinguishes it from sibling tools like create_dynamic_qr or update_dynamic_qr.

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 explicitly states a prerequisite ('Requires an OpenQR API key'), which is important for the agent to know before invoking. However, it does not provide guidance on when not to use this tool (e.g., the need to ensure the correct id is used, or implications of irreversibility).

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It usefully reveals that deleting a folder does not delete its codes (they become un-filed), which is a critical behavioral detail. However, it does not mention whether the operation is reversible, if it requires specific permissions (beyond the API key), or what the response looks like. Given the lack of annotations, this is adequate but not comprehensive.

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

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

The description is concise, consisting of two short sentences. It is front-loaded with the main action, and every sentence adds value. There is no unnecessary information.

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

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

Given the tool's simplicity (1 parameter, no output schema) and the presence of 16 sibling tools, the description is mostly complete but could be improved. It explains the key behavioral nuance (codes are un-filed) and the API key requirement, but it does not state what the tool returns or how to confirm success. For a delete operation, this is a minor gap.

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 input schema has 1 parameter (id) with 0% description coverage, meaning the schema provides no description for the parameter. The description does not add any meaning to the 'id' parameter beyond what is obvious from the schema. Since there is only one parameter, the lack of additional detail is a missed opportunity, but the schema itself is minimal, so a baseline of 3 is appropriate.

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

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

The description clearly states the action ('Delete a folder') and specifies the resource. It also clarifies a key behavioral nuance: codes are un-filed, not deleted. This distinguishes it from other deletion tools like delete_dynamic_qr or delete_theme.

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 mentions an API key requirement ('Requires an OpenQR API key'), which offers some guidance, but it lacks explicit instructions on when to use this tool versus alternatives (e.g., when to use delete_folder vs. delete_dynamic_qr). No exclusions or prerequisites are given beyond the API key.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It discloses that deletion does not affect already styled codes and requires an API key, but it does not mention side effects, idempotency, error behavior, or required permissions.

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, no fluff. The first sentence states the action, the second adds a key behavioral note and a requirement. Every word 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the basics but lacks parameter documentation, usage context, and error handling details. It is adequate but not 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?

The input schema has one required parameter 'id' with 0% schema description coverage. The description does not mention the parameter at all, leaving the agent to infer its meaning from context. This is insufficient for a low-coverage scenario.

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

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

The description clearly states the action ('Delete a saved theme') and resource, distinguishing it from sibling tools like create_theme or list_themes. The additional note about codes retaining their look adds useful context without ambiguity.

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 explicit guidance on when to use this tool versus alternatives (e.g., when to delete vs. update a theme). The prerequisite about requiring an API key is mentioned, but no conditions or exclusions are provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns PNG or SVG and requires an OpenQR API key, which are useful behavioral details. However, it does not mention any side effects, error conditions, rate limits, or whether the operation is stateless. For a simple generation tool, this is decent but not exhaustive.

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

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

The description is two sentences long, front-loaded with the core purpose, and includes key output and authentication details without any fluff. Every word adds value, making it highly concise and well-structured.

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?

The tool is simple (4 params, 1 required) and the description covers purpose, output format, and authentication requirement. It lacks explicit mention of error handling or dynamic vs static trade-offs, but given the schema richness and simplicity, it is adequately complete. No output schema exists, but the output types are stated in the description.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal extra meaning beyond clarifying 'any text/URL' for data and confirming output formats. This aligns with the baseline of 3 when schema handles parameter documentation.

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

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

The description clearly states 'Generate a static QR code' – a specific verb and resource. It distinguishes from siblings like create_dynamic_qr by using 'static', and mentions input (text/URL) and output (PNG/SVG). This is explicit and unambiguous.

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 implies usage for static QR codes but does not explicitly mention when to avoid using it or provide alternative tools. It notes the API key requirement as a prerequisite but offers no guidance on choosing between static and dynamic options. The phrase 'static' hints at the distinction but no explicit 'when-not' or alternative reference is 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?

With no annotations provided, the description carries full burden. It mentions 'Requires an OpenQR API key', which adds essential auth context. However, it does not disclose if the operation is read-only (likely but unconfirmed), what happens if the id is invalid or missing, or any side effects. The description implies a read but doesn't explicitly state it's non-destructive or safe.

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

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

The description is two sentences, both earning their place: the first explains purpose and return fields, the second notes the prerequisite API key. It is front-loaded with the core action. Slightly wordy list of fields could be trimmed, but overall efficient.

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?

The tool has 1 parameter and no output schema, so completeness burden is moderate. The description lists the return fields, which helps the agent understand the output shape despite missing output schema. However, given no annotations and no explicit read-only confirmation, the agent may need to infer behavior. Adequate for a simple read tool but could be more explicit about non-destructive nature.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's 'The code id.' for the one parameter. It does clarify the use case (get full details) but doesn't elaborate on the id format, length, or constraints that the schema might omit.

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

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

The description clearly states the verb 'Get' and the resource 'full details of one of your QR codes by id', listing the specific fields returned. It distinguishes this from sibling tools like 'list_dynamic_qr' (which presumably returns a list without full details) and 'create_dynamic_qr' (which creates rather than reads). However, it could more explicitly differentiate from 'update_dynamic_qr' or other single-code tools.

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

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

The description indicates the tool is for retrieving a specific QR code by ID, implying it should be used when you have a known id and need comprehensive details. It does not explicitly state when not to use it or name alternatives, but given the sibling list, it's clear this is the retrieval-focused tool for a single code.

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 description reveals that an API key is required, which is a behavioral constraint not captured in the input schema. However, it does not disclose what the scan statistics contain (e.g., time range, aggregation), whether the call is read-only, or what happens if the key is invalid. Since annotations are not provided, the description carries the full burden, and additional context would be beneficial.

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

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

The description is extremely concise: two sentences that convey the core purpose and a critical requirement. Every word is informative, and there is no wasted verbiage. The structure is front-loaded with the action and resource.

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

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

Given the tool has 1 parameter, no output schema, and no annotations, the description is adequate but minimal. It does not explain what 'scan statistics' means (e.g., count, dates, devices), which could leave an agent guessing. A bit more detail on the output would improve completeness.

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% with one parameter 'id' described as 'The dynamic code id.' The description adds no further detail about this parameter or its format (e.g., is it a UUID?). It does not explain how the id relates to the scan statistics. Baseline 3 is appropriate as the schema already covers the parameter.

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

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

The description clearly specifies the verb 'Get' and the resource 'scan statistics for a dynamic QR code'. It distinguishes itself from sibling tools like 'get_dynamic_qr' (which likely gets the QR code details) and 'list_dynamic_qr' (which lists codes). However, it does not explicitly differentiate from other scan-related tools that might exist.

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 states a requirement ('Requires an OpenQR API key'), which implies when the tool can be used (only with a valid key). It does not provide guidance on when to use this tool versus alternatives like 'get_dynamic_qr' or 'list_dynamic_qr', nor does it mention any limitations or exclusions.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool shows the subdomain and reports whether it is suspended, and explains the real-world consequence of suspension. No side effects are expected for a read operation, and the description is transparent about this.

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

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

The description is extremely concise: two sentences covering purpose, format, suspension behavior, and authentication. Every sentence is essential and front-loaded. No redundant or extraneous information.

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

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

Given the tool has no parameters and no output schema, the description adequately covers what the tool returns (subdomain and suspension status) and why suspension matters. It also mentions the API key requirement. It could be slightly improved by noting that the subdomain might not be set, but it's sufficient for a simple read tool.

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 has zero parameters, so the baseline is 4. The description adds meaning beyond the empty schema by explaining what the output contains (the subdomain format and suspension status), which is useful context for interpreting the tool's value.

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

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

The description clearly states the tool's purpose: 'Show the branded subdomain on this account' with the format ({name}.oqr.to). It also specifies it reports suspension status, which distinguishes it from sibling tools like set_subdomain and clear_subdomain that perform mutations.

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 provides context for when to use the tool (to check the subdomain and its suspension status) and explains the suspension behavior. It implicitly distinguishes from write tools (set_subdomain, clear_subdomain) but doesn't explicitly state 'use this instead of X when Y.' The API key requirement is noted.

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

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

With no annotations, the description carries the full burden. It mentions the API key requirement, which is useful, but does not disclose pagination behavior, rate limits, or whether the listing is ordered. The 'default 200' hint is in the schema, not the description, so the description adds only the auth context.

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

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

The description is a single, well-structured sentence that front-loads the purpose and includes the key API key requirement. No wasted words, and every part 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?

Given a simple tool with one optional parameter, no output schema, and no nested objects, the description covers the essential purpose and the auth requirement. It could mention whether sorting/ordering applies, but for this complexity level, it is quite 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 coverage is 100% for the single parameter 'limit', and the description does not repeat the schema. The description adds no additional meaning beyond what the schema provides, so 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?

The description clearly states the verb 'list' and the resource 'dynamic QR codes', and it enumerates the fields returned (id, short URL, destination, label, status), which distinguishes it from sibling tools like 'get_dynamic_qr' (single item) or 'bulk_create_dynamic_qr' (creation).

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 implies listing (when you need an overview of codes) but does not explicitly state when to use this tool vs. alternatives like 'get_dynamic_qr' for a single code or 'search' tools. No exclusions or alternative recommendations are provided beyond the implicit sibling list.

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

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

No annotations are provided, so the description carries the full burden. It indicates this is a read-only list operation and requires authentication. However, it does not disclose potential behaviors like pagination, filtering scope, error conditions, or whether the list includes sub-folders. The information is sufficient for basic usage but lacks depth for safe autonomous invocation.

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

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

The description is a single, straightforward sentence with no fluff. It front-loads the purpose and includes a key requirement. However, it could be slightly more complete without becoming wordy. The conciseness is good but not exceptional given the opportunity to add more behavioral context.

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

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

Given there is no output schema and no annotations, the description should provide enough detail for correct tool usage. It states what it returns and the auth requirement, but omits important context like whether results are paginated, how to handle errors, or if there are any access scope limitations. The description meets basic needs but leaves gaps for complex agent decision-making.

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 input schema has zero parameters and 100% schema description coverage (vacuous). The description adds value by explaining what is returned ('id and name') and that authentication is needed. Since there are no parameters to document, the baseline of 4 is appropriate—the description provides useful operational context 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?

The description clearly states the action ('List your folders') and the resource ('folders'), explicitly mentioning the returned fields ('id and name'). This directly distinguishes it from sibling tools like create_folder, delete_folder, and other list tools by specifying the exact resource being listed.

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 provides no guidance on when to use this tool versus alternatives. It only mentions a prerequisite ('Requires an OpenQR API key'), which is an authentication detail rather than a usage context. There is no comparison to siblings or conditions where another tool would be preferable.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses an authentication requirement ('Requires an OpenQR API key') and the verb 'List' implies a non-mutating read, but it does not state read-only behavior, return format, or potential errors.

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 scope. Every word earns its place; the auth requirement is appended without clutter.

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 read operation with no output schema, the definition is mostly sufficient: it states what is listed, the target resource, and the required credential. It could be richer with return-value or pagination notes, but these are minor for this complexity level.

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

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

Schema description coverage is 100%, so the schema already fully documents the single id parameter. The description merely echoes the notion of 'one dynamic code' and adds no new parameter-level detail.

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

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

The description states a specific verb ('List'), a specific resource ('link aliases'), and a clear scope ('of one dynamic code'). It is naturally distinguished from siblings like create_link_alias and list_dynamic_qr, though it does not explicitly name them.

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 intended use is implied by the purpose: call this when you need the link aliases for a particular dynamic code. However, there is no explicit guidance about when not to use it or which sibling tool should be chosen instead.

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

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

No annotations are provided, so the description carries full burden. It clearly states it is a read operation (list), returns specific fields, and requires an API key. Lacks mention of edge cases (e.g., empty result behavior) but is sufficient for a simple list tool.

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

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

Two concise sentences, first states purpose and result, second adds usage guidance and requirement. No fluff, each sentence 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?

Given no parameters, no output schema, and no annotations, the description covers purpose, output details, usage context, and authentication. It is complete for a simple list operation with no input.

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?

There are no parameters, so schema description coverage is 100% trivially. The description adds value by explaining the output and usage, but for this dimension (parameter semantics), it cannot add beyond the empty schema. Baseline score 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?

The description uses specific verb 'List' and resource 'saved style themes' with return fields (id, name). It clearly distinguishes from sibling tools like create_theme and delete_theme, serving as the retrieval counterpart.

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 explains how to use the output (pass id/name as `theme` to generate/create/update tools) and mentions the API key requirement. Implicitly tells the agent when to use this tool, though not explicitly stating alternatives or when not to use.

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

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 clearly discloses the scope of the change (affects branded subdomain), reassures that plain short links remain functional, and mentions the Pro requirement. Though it does not detail the full request/response lifecycle, it provides sufficient transparency for a single-parameter mutation tool.

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

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

The description is three short sentences that front-load the core action ('Claim or change the branded subdomain'), then add necessary constraints and reassurances. Every sentence adds useful information with no repetition or filler.

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

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

Given the low complexity (single parameter, no output schema, no nested objects), the description is complete enough. It covers purpose, prerequisites, and a behavioral guarantee. The only minor gap is not stating the return value or success/failure cues, but for a mutation tool this is acceptable.

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 schema coverage is 100% with a clear description for the subdomain parameter. The description adds value by explaining the effect of the parameter ('so codes also resolve at {name}.oqr.to') and gives an example format. This goes beyond the schema's basic type/description, earning above 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?

The description uses a specific verb sequence ('Claim or change') and clearly identifies the resource (branded subdomain). It distinguishes itself from siblings like get_subdomain, clear_subdomain, and other domain-related tools, making its purpose unmistakable.

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 mentions 'Pro only' and 'Requires an OpenQR API key,' providing important prerequisites. It also clarifies a key context: changing the subdomain does not break existing short links. However, it does not explicitly state when to use set_subdomain versus siblings like bulk_create_dynamic_qr or other tools, but the context is clear enough for an AI agent.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It does mention the auth requirement and the partial-update semantics, which are helpful. However, it doesn't disclose potential side effects (e.g., whether changing status pauses the code immediately, or what happens to existing fields not passed beyond the implied retention). It also lacks information about rate limits or reversibility. For a mutation tool, this is adequate but not rich.

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

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

The description is two sentences with zero waste. It front-loads the core purpose and then gives the partial-update guidance and auth requirement. Every sentence 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?

Given the tool has 14 parameters and no output schema, the description is thin. It covers the auth requirement and the partial-update behavior, but omits return value details (though no output schema exists), error handling, and any prerequisites (e.g., the code must exist). It also doesn't mention any consequences of pausing or scheduling. For a tool this complex, more context would help an agent avoid mistakes.

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

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

Schema description coverage is 100%, so the baseline is 3. The description merely lists the editable fields (destination, label, slug, tags, folder) without adding meaning beyond what the schema already provides (e.g., constraints, null semantics). It adds little extra value for parameter comprehension.

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

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

The description states a clear verb and resource: 'Edit a dynamic QR code' and lists the editable fields (destination, label, slug, tags, folder). This distinguishes it from sibling tools like create_dynamic_qr and delete_dynamic_qr, though it doesn't explicitly name those alternatives. It's unambiguous about the operation.

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 phrase 'Pass only the fields you want to change' implies partial updates, which is useful guidance. It also mentions the API key requirement. However, it does not explicitly state when to use this tool vs alternatives (e.g., when to use bulk_create_dynamic_qr instead), nor does it provide exclusions or prerequisites beyond authentication.

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