Brandize

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

Beyond the annotations, the description discloses that this is a paid purchase, creates a checkout link, requires payment before the deliverable changes, and offloads Terms of Service/Privacy consent to the hosted checkout page. It also tells the agent to poll get_logo_result with the same jobToken. This is rich, useful behavioral context that goes far beyond readOnlyHint/destructiveHint.

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 front-loaded with the core purpose and then covers payment, checkout, consent, and result retrieval in a compact flow. It is reasonably concise, though 'This is a paid purchase' is slightly redundant after 'Purchase' and 'Priced the same as the PREMIUM tier.' Overall it is well-structured 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 two-parameter purchase tool with an output schema, the description covers the essential prerequisites, the payment/checkout flow, the deliverable transition, consent handling, and how to retrieve the purchased result. Nothing critical needed to call the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context by confirming that jobToken is the same token used later with get_logo_result and that variationId comes from generate_logo_variations. This lifecycle relationship is not present in the schema and helps the agent use the parameters correctly.

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 object: 'Purchase one of the alternate designs from generate_logo_variations instead of the original logo.' This clearly distinguishes the tool from generate_logo_variations (which generates designs) and generate_logo (which produces the original), leaving no ambiguity about what it does.

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

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

The description gives clear context: it is for buying an alternate variation, not the original logo, and it references the correct source tool, generate_logo_variations. It also explains the post-purchase flow with get_logo_result. However, it does not explicitly state when not to use it or name direct alternatives as exclusions, 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?

Annotations already declare readOnlyHint=true, covering the safety profile. The description adds behavioral context beyond that: it confirms the message is returned verbatim and that this verifies endpoint reachability.

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?

Single sentence, front-loaded with the tool's identity ('Health check'), and contains no filler. Every word contributes meaning.

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 trivial one-parameter read-only tool with a full output schema and clear annotations, the description fully covers what an agent needs: purpose, behavior, and parameter semantics.

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

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

Schema description coverage is 100% and the message parameter is already documented as 'Text to echo back unchanged.' The description's 'returns the provided message verbatim' reinforces but doesn't add new semantic information. Baseline 3 applies.

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

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

Description states a clear verb and resource: it returns the provided message verbatim as a health check. This distinguishes it from sibling tools that generate logos or search blogs, making selection 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 frames when to use this tool: as a connectivity health check for the Brandize MCP endpoint. It doesn't name alternatives or exclusions, but the health-check context effectively communicates its narrow usage scope.

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

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

Annotations already declare readOnlyHint=true, and the description adds useful behavior: the palette is exactly 5 colors and the result can be returned in three distinct formats. No side effects or destructive behavior are implied, and nothing contradicts the annotations.

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 zero filler. The core action and inputs are front-loaded, and the output formats are listed compactly. 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?

For a simple, read-only, pure generation tool, the description covers the essential inputs, output formats, and result size. An output schema is present, so return values are adequately specified elsewhere, and no critical guidance is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the output format enum values ('CSS custom properties', 'Tailwind config snippet', 'plain hex list') and framing the result as a 'brand palette', which helps the agent understand the tool's purpose.

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: 'Generate a 5-color brand palette.' It clarifies the core inputs (base hex color and harmony rule) and names concrete output formats, making it immediately distinguishable from the logo, meta-tag, and search 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?

The description gives clear usage context by specifying what inputs are expected and what outputs are produced. It does not explicitly mention exclusions or alternatives, but the sibling tools are so unrelated to color palette generation that confusion is unlikely.

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 clearly discloses the paid purchase, the watermark-only preview, the full-resolution deliverable gated behind payment, the upgrades list, and that the hosted checkout collects ToS/Privacy consent. This is substantial behavioral context beyond the annotations, which only state that the tool is non-read-only and non-destructive. There is no annotation contradiction.

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 front-loaded with the core action, then organizes required user inputs into a numbered brief and follows with return/payment/follow-up behavior. Although it is long, each sentence carries distinct operational information and there is no filler.

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

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

For a paid, asynchronous generation tool with 10 parameters, the description covers the full lifecycle: pre-call brief, parameter confirmation rules, immediate return value, upgrades, payment-gated deliverable, and retrieval via get_logo_result. The output schema covers the return structure, so no critical operational information is missing.

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

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

Schema coverage is 100 percent, so the baseline is 3. The description adds real value by mapping the design brief items to the required parameters (tier, style, color scheme, layout, primary surface, industry) and establishing the confirm-before-generating rule for unspecified fields. This justifies a point 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 opening phrase names the specific operation and resource ('Generate a brand logo'), and the rest details the deliverable and workflow. It is clearly the main logo-creation entry point and distinguishably different from result-poller tools like get_logo_result, but it does not explicitly contrast itself with generate_logo_variations, so it stops short of full sibling differentiation.

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

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

It gives explicit pre-call instructions: collect a design brief, never assume defaults, and propose-and-confirm when the user has no preference. It also tells the agent to poll get_logo_result with the returned jobToken after payment. However, it does not explicitly state when to prefer sibling tools like generate_logo_variations or generate_color_palette, so exclusion guidance is absent.

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 only readOnlyHint=false and destructiveHint=false in annotations, the description carries the full behavioral burden and meets it thoroughly. It discloses that it is free but limited by credit, returns a watermarked low-res preview, reports remaining credits, and alters behavior on purchased jobs (adds alternates, or refuses). This goes far beyond the minimal annotation hints and provides 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?

The description is long but dense, front-loaded with the core purpose and then structured into cost, return type, purchase flow, and tier-specific behavior. Each sentence carries distinct information, and the length is proportional to the behavioral complexity. It could be tightened slightly, but it remains well-organized and readable.

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 complexity (multiple purchase tiers, credit limits, return format) and the existence of an output schema, the description covers every aspect an agent needs: what it does, what it returns, how credits work, when to use buy_logo_variation, and how behavior changes on purchased jobs. No critical gap is left to inference.

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, but the description adds meaning beyond the schema by explaining that 'count' is 'capped by the free-preview credits remaining on this job' — a constraint not in the schema. It also ties jobToken to generate_logo's output. These additions justify a 4.

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 precise verb+resource: 'Generate alternate style directions for an existing generate_logo job.' It clearly distinguishes itself from generate_logo (which creates the original) and buy_logo_variation (which purchases), and it names the prerequisite job. The free-preview credit note reinforces its specific role among 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 explicitly states when to use this tool versus alternatives: 'Before any purchase, each result's variationId can be passed to buy_logo_variation to purchase that design instead of the original.' It also explains the conditional behavior on different purchase tiers (COMPLETE adds alternates, other tiers refuse), giving clear when-to-use and when-not-to-use guidance, including a pointer to get_logo_result for retrieval.

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

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

Annotations declare readOnlyHint=true, which is consistent with a generation tool. The description adds useful context about the output being an HTML <head> block and that all inputs are optional, but it does not disclose how omitted fields are handled (e.g., omitted entirely versus defaulted) or whether the output is a complete standalone snippet. The output schema mitigates some of this gap.

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 sentence that front-loads the action and output while packing the key scope (HTML <head> block, tag categories) and flexibility constraint 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?

For an 11-parameter generator, the parameter schema fully documents each field and the output schema covers return structure, so the description does not need to re-explain them. The main missing guidance is behavioral detail about empty or absent fields, but this is minor given the schema coverage and read-only annotation.

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

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

Schema description coverage is 100%, and each parameter already has meaningful descriptions, including fallback behavior for ogTitle, ogDescription, and canonical. The description adds only the high-level 'All fields optional' note, which is also implied by the zero required parameters, so it does not meaningfully go 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 names a specific verb ('Generate'), a concrete resource ('HTML <head> meta-tag block'), and enumerates the tag types included (title, description, canonical, robots, Open Graph, Twitter Card). This clearly separates it from the sibling generate_schema_markup tool, which produces structured schema markup rather than meta tags.

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 'from page details' implies the input context, and 'All fields optional' conveys that any subset of fields can be supplied. However, it does not explicitly state when to prefer this tool over alternatives like generate_schema_markup, nor does it mention any exclusions or prerequisites.

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

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

Annotations declare readOnlyHint=true, so the agent already knows this is a safe pure-transformation operation, and the description's 'Generate' verb is consistent with that. The description adds useful behavioral context beyond the annotations: the input must be a 'flat data object' and FAQPage requires the specific data.items structure. No contradiction with annotations.

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 filler. The primary purpose and type list are front-loaded in the first sentence, and the FAQPage edge case is isolated in the second. Every clause 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 read-only generation tool with an output schema (which covers return format) and a fully documented input schema, the description is nearly complete: purpose, supported types, input shape, and the one special case (FAQPage) are all covered. The only gap is explicit routing against the sibling generate_meta_tags, which was already noted under usage guidelines.

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 both parameters, including the enum values for type and the example data shape plus the FAQPage items format. The description largely restates this schema content ('flat data object', 'pass data.items as [{ question, answer }]'), adding little new meaning beyond what the schema provides. 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 states a specific verb (Generate), a concrete resource (a JSON-LD <script> block), and enumerates the six supported schema.org types. This clearly distinguishes it from the sibling generate_meta_tags, which produces HTML meta tags rather than structured JSON-LD.

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 its usage context by naming JSON-LD as the output format and listing the supported types, which lets an agent infer when to pick it over generate_meta_tags. However, there is no explicit when-to-use/when-not-to-use statement, no exclusions, and no named alternative, so the routing guidance is left to inference.

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

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

Annotations already set readOnlyHint=true, and the description reinforces it with 'Read-only and safe to poll'. It adds valuable behavioral context: pending status before payment, polling interval, and non-instant confirmation. No contradiction with annotations.

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, front-loaded with purpose and then timing details. Every word earns its place with no redundancy. Very 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?

An output schema exists, so return values don't need explanation. The description covers the polling workflow, status behavior, and timing constraints completely for a single-parameter tool. Nothing essential is missing.

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

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

Schema coverage is 100% for the single parameter jobToken, including a clear description referencing generate_logo. The tool description repeats the parameter name but adds no new semantic detail beyond the schema, so baseline 3 applies.

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

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

The description states a specific action (poll a logo job) and resource (by jobToken), and clarifies the outcome (download URL or pending status). It clearly distinguishes itself from sibling tools like generate_logo or buy_logo_variation by focusing on result retrieval.

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

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

Provides explicit guidance on when to use (after payment settles) and how to poll (every ~5 seconds, up to a few minutes). It implies not to use before payment, though it doesn't name an alternative tool explicitly. The 'safe to poll' note adds usage clarity.

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 annotations already declare readOnlyHint=true, and the description mostly restates that with 'Read-only; nothing is purchased.' It adds no new behavioral details such as authentication requirements, rate limits, or response behavior beyond what the output schema already covers. The description does not contradict the annotations.

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 sentence that states both the action and the key output details up front. Every word contributes meaning, with no filler or repetition beyond the useful read-only reassurance.

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

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

For a zero-parameter, read-only, output-schema-backed tool, the description is complete. The agent knows what the tool lists, that it is safe to call, and the output format is available via the output schema, so no additional detail is required.

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?

With zero parameters and 100% schema coverage, there is nothing for the description to clarify. The description appropriately focuses on the semantic meaning of the returned data (price and included features) rather than parameter syntax, so the baseline 4 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 begins with a specific verb ('List') and a concrete resource ('Brandize service tiers'), then adds the exact scope: price (USD) and included features. It is clearly distinguishable from the sibling logo-generation and purchase tools, so an agent can identify what this tool does without inspecting the schema.

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

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

The description gives clear context by stating that the tool is read-only and that 'nothing is purchased,' which signals a safe informational call. It does not explicitly name an alternative tool for when purchasing is intended, but the context is strong enough to guide basic 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?

Annotation readOnlyHint=true already covers safety. The description adds meaningful context by specifying the content domain and the shape of the result (titles, excerpts, URLs), which goes beyond the annotation without contradicting it.

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

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

A single, front-loaded sentence conveys the resource, scope, action, and return value with no filler. Every element earns its place.

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

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

For a single-parameter, read-only search tool with an output schema, the description covers the domain, the action, and the result shape. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents the 'query' parameter's meaning. The description's mention of 'by keyword' is consistent but does not add significant new semantics 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 uses a specific verb ('Search'), a clear resource ('Brandize blog posts'), and a scope ('logo design and branding guides'). It also states what is returned (titles, excerpts, URLs), making the tool's purpose immediately distinguishable from the generation and retrieval 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?

The description makes the use case clear: search blog content by keyword. It does not explicitly name alternatives or exclusion conditions, but no sibling tool is a blog search, so the appropriate context is effectively unambiguous.

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