Server Quality Checklist

Tool Scores

• get-blocks-metadataD
  1.9/5.0
  Behavior2/5

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

  No annotations provided, so the description should fully disclose behavior. It claims to fetch metadata but does not state whether it is read-only, if it requires a URL (contradicts schema), or what the output format is. The mention of 'all blocks' versus 'from a given URL' is unclear.

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

  Conciseness2/5

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

  The description is short but redundant: 'Fetch the metadata' and 'retrieve the block metadata' say the same thing. The inconsistency between URL and all blocks adds confusion, wasting the brevity.

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

  Completeness2/5

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

  Given no parameters and no output schema, the description should at least clarify what metadata is returned (e.g., list of properties) and resolve the URL contradiction. It fails to provide a complete understanding of the tool's behavior.

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

  Parameters1/5

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

  The input schema has zero parameters, but the description incorrectly implies a URL parameter ('from a given URL'), misleading the agent. Since there are no parameters, the description should confirm that no input is needed, but instead it suggests an undefined parameter.

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

  Purpose2/5

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

  The description states 'Fetch the metadata of a block from a given URL' but the input schema has no URL parameter, creating a contradiction. It also conflates retrieving a single block's metadata with 'all the FlyonUI blocks', causing ambiguity. No differentiation from sibling tools like get-block-content or get-block-meta-content.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus siblings. The description only says 'Use this tool to retrieve block metadata' but does not explain why one would choose it over get-block-content or get-block-meta-content.

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

• get-block-meta-contentC
  2.3/5.0
  Behavior2/5

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

  No annotations exist, and the description only states 'Fetch', implying read-only, but does not disclose any behavioral traits such as side effects, required permissions, rate limits, or response structure.

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

  Conciseness2/5

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

  The description is extremely short (two sentences), but it lacks necessary information, making it under-specified rather than concise. Every sentence is vague.

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

  Completeness1/5

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

  Given no annotations, no output schema, and a single undocumented parameter, the description fails to provide adequate context for an agent to use the tool effectively.

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

  Parameters1/5

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

  The input schema has a single required parameter 'endpoint' with no description, and the description provides zero information about its meaning, format, or valid values (0% schema description coverage).

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

  Purpose4/5

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

  The description uses verbs 'Fetch' and 'retrieve' with the resource 'block metadata content', but it doesn't clearly differentiate from sibling tools like 'get-block-content' or 'get-blocks-metadata', leaving ambiguity about what 'metadata content' specifically means.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites or exclusions, leaving the agent without decision criteria.

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

• get-block-contentC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, and the description only implies a read operation ('Fetch'). It mentions 'authenticated URL' but does not disclose other behavioral traits such as side effects, rate limits, or error conditions.

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

  Conciseness4/5

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

  The description consists of two concise sentences that efficiently convey the core action and usage intent. Minor redundancy ('from a given URL' and 'from the authenticated URL') does not significantly detract.

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

  Completeness2/5

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

  With no output schema, no annotations, and two undocumented parameters, the description fails to explain the output format, the meaning of 'type', or what constitutes a 'block'. Siblings exist but are not differentiated.

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

  Parameters2/5

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

  The schema has 0% description coverage for parameters. The description only hints that 'endpoint' is a URL but does not explain the 'type' parameter or provide format details beyond what the schema names show.

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

  Purpose4/5

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

  The description clearly states it fetches block content from a URL and specifies 'code block content', which differentiates it from siblings like 'get-block-meta-content' that likely fetch metadata. However, it does not explicitly contrast with siblings.

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

  Usage Guidelines2/5

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

  The description says 'Use this tool to retrieve the code block content from the authenticated URL' but provides no guidance on when not to use it or how it compares to alternative sibling tools.

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

• get-create-instructionsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavior. It states the tool provides instructions but does not clarify if it is read-only, requires authentication, or has side effects. The instruction to 'strictly follow steps' hints at process, but deeper behavioral traits are missing.

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

  Conciseness3/5

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

  The description is repetitive ('Get instructions for...using existing blocks' is stated twice) and contains a run-on sentence at the end. It is not overly long but could be more concise.

  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?

  Despite having no parameters or output schema, the description fails to specify the format or content of the returned instructions. It is adequate for a simple instruction-retrieval tool but lacks detail on what the output contains.

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

  Parameters4/5

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

  The input schema has zero parameters with 100% schema description coverage, so the description adds no parameter-level meaning. Per guidelines, 0 parameters warrants a baseline of 4.

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

  Purpose4/5

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

  The description clearly states that the tool retrieves instructions for creating/generating/updating FlyonUI blocks, and it specifies a trigger phrase ('mentions /create-flyonui or /cui'). However, it does not distinguish well from sibling tools like 'get-refine-instructions'.

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

  Usage Guidelines3/5

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

  The description includes explicit guidance on when to use ('when the user requests to generate a new component') and mentions specific triggers, but it lacks explicit exclusion criteria or comparisons to alternatives.

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

• get-inspire-instructionsA
  4.1/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It describes the action (get instructions) but does not disclose any side effects, permissions, or format of output. Adequate but not rich.

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

  Conciseness5/5

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

  Two sentences, every word earns its place. Purpose and trigger conditions are front-loaded with no redundancy.

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

  Completeness3/5

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

  For a simple tool with no output schema, the description gives purpose and usage but does not explain the format or content of the instructions returned. Adequate but could be more complete.

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

  Parameters4/5

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

  No parameters in schema, and description does not need to add parameter info. Baseline 4 for 0 parameters as per guidelines.

  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 provides instructions for creating new FlyonUI blocks by inspiration, with specific trigger phrases. It distinguishes from siblings like get-create-instructions.

  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?

  Explicitly states when to use ('when the user requests to generate a new component by inspirations' and trigger phrases), but does not explicitly exclude alternatives.

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

• get-refine-instructionsA
  4.3/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It states its function but doesn't disclose details like return format or constraints, though it's a simple query tool.

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

  Conciseness4/5

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

  Three sentences with front-loaded purpose, but second sentence is somewhat redundant. Overall concise and well-structured.

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

  Completeness4/5

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

  For a simple tool with no parameters or output schema, description covers purpose, usage context, and trigger phrases. Could mention return type but not essential.

  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 in schema, so description doesn't need to add param info. It appropriately lacks param details.

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

  Purpose5/5

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

  Clearly states it provides instructions for refining FlyonUI blocks, and distinguishes from siblings like get-create-instructions by specifying 'refine an existing component'.

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

  Usage Guidelines5/5

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

  Explicitly says to use when user requests to refine an existing component, and gives trigger mentions /refine-flyonui or /rui, providing clear context and alternative.

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