Server Quality Checklist

Tool Scores

• markitup_extendA
  3.9/5.0
  Behavior3/5

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

  Without annotations, the description carries the full burden. It mentions the credit cost but does not disclose other behavioral traits such as output format, synchronous/asynchronous behavior, error conditions, or whether the operation is reversible. The description provides minimal behavioral context beyond the basic action.

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

  Conciseness5/5

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

  The description is extremely concise with two sentences that front-load the purpose and immediately follow with usage context and parameters. No redundant or unnecessary information is present.

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

  Completeness3/5

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

  Given the complexity (7 parameters, no output schema, no annotations), the description covers the essential purpose and usage but lacks details on output format, direction of extension, or error handling. It is adequate for a basic understanding but not fully comprehensive.

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

  Parameters3/5

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

  The schema has 71% description coverage, so the description's added value is limited. It reiterates that parameters include source image (URL or base64) and target dimensions, but does not explain the 'image_size' enum or add semantics beyond what the schema already provides. This meets the baseline for moderate coverage.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'AI-outpaint an image to a larger canvas.' It provides specific use cases like converting a square asset to different aspect ratios, which distinguishes it from sibling tools that generate, regenerate, or remove backgrounds.

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

  Usage Guidelines4/5

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

  The description gives explicit use cases ('converting a square asset to 16:9 or 9:16, or extending a tight crop') and mentions cost ('Costs 1 credit'). However, it lacks explicit comparison to alternatives or when not to use it, though the context from sibling names implies differentiation.

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

• markitup_credit_balanceA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It correctly implies a safe, read-only operation without causing side effects, which is adequate for a simple balance check.

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

  Conciseness5/5

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

  Two concise, front-loaded sentences with no wasted words. Every sentence adds value: purpose first, usage guidance second.

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

  Completeness3/5

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

  While adequate for the tool's simplicity, it lacks details about the return structure (e.g., whether balance is an object or just a number). With no output schema, more specificity would improve completeness.

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

  Parameters4/5

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

  No parameters exist (0 params, 100% schema coverage). Description adds value by explaining what the tool returns, fulfilling the baseline expectation for zero-parameter tools.

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

  Purpose5/5

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

  The description explicitly states it returns 'current MarkItUp credit balance and subscription status for the authenticated account', clearly distinguishing it from sibling generation tools.

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

  Usage Guidelines4/5

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

  It gives explicit guidance: 'Use this before calling generation tools to verify the account has credits available.' No explicit when-not, but context is clear.

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

• markitup_remove_backgroundA
  4.3/5.0
  Behavior4/5

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

  Discloses output is transparent PNG, cost of 1 credit, free for Pro/Power subscribers. No annotations provided, so description carries burden; it covers key behaviors but omits error handling or rate limits.

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

  Conciseness5/5

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

  Two sentences, front-loaded with purpose, then cost and input format. No wasted words.

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

  Completeness5/5

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

  For a medium-complexity tool, description covers purpose, input, output, and cost. No output schema, but output described as transparent PNG. Enough for agent to decide.

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

  Parameters3/5

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

  Schema has 67% description coverage. Description adds context that image_url and image_base64 are mutually exclusive and mentions mime_type default. Adds some value, but schema already covers basics.

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

  Purpose5/5

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

  The description clearly states it removes background from an image using Photoroom HD AI, returns transparent PNG. Distinct from siblings (credit_balance, extend, generate, regen) which are unrelated.

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

  Usage Guidelines4/5

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

  Specifies input format (URL or base64) and credit cost. Implicitly suggests usage for background removal, but no explicit when-to-use or alternatives among siblings.

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

• markitup_regenA
  4.4/5.0
  Behavior4/5

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

  Without annotations, the description discloses important behaviors: credit cost (if charge_credit=true), the need to reuse previous text_analysis to maintain visual consistency, and the use of variation_index to select a slot. This goes beyond simple purpose.

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

  Conciseness5/5

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

  The description is front-loaded with the main purpose and logically organized. Each sentence adds distinct value (prerequisite, cost, required arguments, slot selection). No redundant or irrelevant information.

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

  Completeness4/5

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

  Despite no output schema, the description covers key usage aspects: required inputs from previous call, variation selection, credit cost. It does not explain the return format, but the regeneration context is adequately described for an agent to infer the output.

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

  Parameters4/5

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

  Schema coverage is 78%, and the description adds context by explaining the relationship between text_analysis and the previous generate's structuredContent.text, and clarifying variation_index as a slot. This provides meaning beyond the schema definitions.

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

  Purpose5/5

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

  The description uses the specific verb 'Regenerate' and clearly identifies the resource as 'a single variation from a previous markitup_generate call'. It distinguishes from sibling tools (e.g., markitup_generate) by referencing the prerequisite generation call.

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

  Usage Guidelines4/5

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

  The description provides instructions on when to use the tool (after a markitup_generate call) and how to pass required data (source image, text_analysis object, variation_index). It also mentions credit cost. Missing explicit when-not-to-use scenarios, but context is clear.

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

• markitup_generateA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description covers cost (1 credit), the multi-model pipeline (Claude + Gemini), and return value (images + copy), providing adequate behavioral context.

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

  Conciseness5/5

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

  Description is only 3 sentences, each serving a purpose: purpose/pipeline, cost/input constraint, template IDs/output. Perfectly front-loaded.

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

  Completeness5/5

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

  Given 7 parameters and no output schema, the description covers necessary context: input methods, cost, style options, and what is returned. No gaps.

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

  Parameters4/5

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

  Schema coverage is 100%, but the description adds value by clarifying the mutual exclusivity of image_url/image_base64 and listing example template_ids beyond schema defaults.

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

  Purpose5/5

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

  The description clearly states the tool generates polished marketing-visual variations using a specific pipeline, distinguishing it from siblings like markitup_extend or markitup_remove_background.

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

  Usage Guidelines4/5

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

  The description explicitly says to provide either image_url or image_base64 (exactly one) and lists common template IDs, but lacks explicit when-not-to-use guidance or comparisons to siblings.

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