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 provided, the description must disclose behaviors itself. It does so by stating that static codes bake content into the code permanently, are not editable, and lack scan analytics. It also mentions the API key requirement. This covers persistence, mutability, and auth needs, but does not detail error scenarios, rate limits, or library interactions beyond 'save'.

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, each adding value: purpose, static-vs-dynamic trade-offs, and usage requirements. The core action is front-loaded, and there is no redundant wording.

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 involves nested fields and multiple payload types, but the schema covers those. The description covers prerequisites (API key), the follow-up rendering step, and the permanence trait. It does not describe the return payload, but since no output schema exists, this is acceptable. Overall, an agent has enough to call it correctly.

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

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

The input schema already provides 100% coverage with detailed per-type field descriptions. The description lists the supported payload types but does not add meaning beyond what the schema exposes. Since schema coverage is high, the baseline 3 is appropriate; the description doesn't compensate with extra parameter context.

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' with a specific resource ('static QR code') and a defined scope ('from structured fields'). It also distinguishes static from dynamic QR codes by mentioning the absence of short links and analytics, which differentiates it from sibling tool 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 implies when to use this tool over dynamic QR by highlighting trade-offs (no short link, no analytics, not editable), and it gives a prerequisite (requires an OpenQR API key). It also provides a follow-up action (render with generate_qr). It lacks an explicit 'use this when...' statement, but the contrast with static vs dynamic is sufficient for an agent to infer selection.

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 behavioral burden. It discloses the API key requirement and output format, but does not mention other important behaviors such as the non-editable nature of static codes (permanence) or any rate limits/error conditions. This is a modest but incomplete disclosure.

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

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

Two concise sentences with the primary purpose front-loaded. Every word earns its place, no fluff.

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 4-parameter tool with full schema coverage, the description is quite complete. It covers the key functional distinction (static vs dynamic), output format, and authentication. It does not provide an exhaustive list of edge cases, but that is acceptable for a simple QR generator. Slight lack of explicit guidance on choosing static over dynamic keeps it from a 5.

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 adds no parameter-specific information beyond what the schema already provides; it merely echoes 'text/URL' which matches the data parameter. No added value in describing parameters.

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 from any text/URL' with a specific verb and resource. It also specifies the return type (PNG image or SVG markup) and distinguishes itself from sibling dynamic QR tools by using the word 'static'.

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, contrasting with dynamic tools like create_dynamic_qr. However, it does not explicitly mention when not to use it or name alternative tools. The API key requirement is a clear prerequisite.

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 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, the description carries the transparency burden. It does disclose partial-update behavior and API-key auth requirements, which is useful. However, it does not explain what the operation returns, whether changes take effect immediately, or any side effects or reversibility, so transparency is only partially addressed.

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 no filler. It front-loads the core purpose, gives the most important usage rule, and states the 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?

For a tool with 14 optional parameters and no output schema, the description provides only the essential editing context and auth requirement. The schema covers parameters well, but the description lacks guidance on what to expect back from the call and does not clarify edge cases such as preserving unspecified fields, though 'pass only the fields you want to change' partially implies it.

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

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

Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds partial-update context and mentions a subset of parameter names, but does not add substantial meaning 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 it edits a dynamic QR code and names several concrete editable fields (destination, label, slug, tags, folder), making the resource and action unambiguous. It does not explicitly differentiate itself from sibling tools, but the edit/update semantics are clear against create/delete/list siblings.

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 gives practical partial-update guidance ('Pass only the fields you want to change') and the prerequisite that an OpenQR API key is required. However, it does not explicitly say when to prefer this tool over alternatives like create_dynamic_qr or bulk_create_dynamic_qr, leaving that to inference from the tool name and siblings.

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