Server Quality Checklist

Tool Scores

• get_recipe_widget_dataD
  1.6/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior. It mentions that base64 photo data URIs stay out of model context and describes a call pattern, but does not clarify whether this is a read-only operation, what side effects exist, or what the output structure is. The information provided is more about internal plumbing than tool behavior.

  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 a single run-on sentence filled with jargon (e.g., 'Krea's get_job pattern', 'host-relayed tools/call') without being front-loaded with the core purpose. It is not concise or well-organized for an agent to quickly understand the tool.

  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?

  Despite having only one parameter and no output schema, the description fails to explain what data the tool returns, what the recipe_id refers to, or how the tool fits into the agent's workflow. It is written for developers maintaining the system, not for an AI agent selecting and invoking the tool.

  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?

  Schema description coverage is 0%, and the description does not explain the recipe_id parameter at all. The parameter only has a type and title, so the agent has no idea what value to pass or how it relates to the tool's function.

  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 mentions 'app-only data feed for the Mela recipe card' but lacks a clear verb+resource structure. It doesn't state what the tool actually returns or does in a way an agent can act on. It does not distinguish itself from siblings like get_recipe or search_recipes beyond saying it is app-only.

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

  Usage Guidelines1/5

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

  The description explicitly says the widget iframe calls the tool itself and it is 'never surfaced to the model,' implying the agent should not use it. No alternatives or conditions are provided. This gives no actionable guidance for when an agent should invoke this tool.

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

• search_recipesA
  4.2/5.0
  Behavior4/5

  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 key behaviors: 'All words must match' for query semantics, return fields (id/title/tags/snippet), and that results are text only with no photos, requiring get_recipe for photos. This goes well beyond the schema.

  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?

  Three concise sentences, each earning its place: purpose/filter overview, return summary, and cross-reference to get_recipe. It is front-loaded with the main action and contains no filler.

  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?

  Given an output schema exists and parameters are simple, the description covers the essential aspects: search semantics, filters, return severity, and how to get full recipes. Missing a mention of the limit parameter is a minor gap, but overall it is complete enough for an agent to use correctly.

  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 description adds meaning for the query parameter ('All words must match') and lists tag, favorite, and want_to_cook as optional filters. However, it does not describe the limit parameter or clarify the meaning of boolean filters beyond their names. Since schema descriptions are absent (0% coverage), this is a partial compensation.

  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 opens with a specific verb+resource: 'Full-text search the Mela recipe library.' It clearly distinguishes from siblings by stating that results are summaries (id/title/tags/snippet) and directing users to get_recipe for full details, including photos.

  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 provides a clear workflow: first use search_recipes, then call get_recipe with a result id to see the full recipe with photos. This implies when to use this tool vs get_recipe, though it does not explicitly discuss other siblings like list_tags or state exclusions.

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

• get_recipeA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It explicitly discloses that real photos are not provided as content to the agent, only rendered in a card, and instructs not to describe or substitute photos. It also lists what fields will be returned. It lacks error/edge-case behavior, but for a read-only get operation, this is a meaningful disclosure that goes beyond obvious behavior.

  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 is concise and front-loaded with the core purpose. The additional sentences about MCP Apps and photo handling are useful and directly inform agent behavior, though the MCP Apps detail could be seen as slightly verbose. Overall each sentence earns its place.

  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 single-parameter tool, the description covers the input source, return content, and a critical behavioral caveat (photos not available). It doesn't mention not-found errors or permissions, but those are less critical given the simple read-only nature and no output schema. It is complete enough for effective use.

  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 schema is sparse (one integer `recipe_id`, 0% coverage), but the description compensates by specifying 'by its numeric id from search_recipes'. This tells the agent the id is numeric and comes from the search tool's results, which is valuable beyond the schema's bare type definition.

  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 states a precise action: 'Get one recipe's full detail' with a specific resource (recipe by numeric id) and lists the included content (ingredients, instructions, notes, times, tags). It clearly distinguishes from siblings like search_recipes (which lists) and get_recipe_widget_data (which returns widget data, not full detail).

  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 phrase 'from search_recipes' clearly instructs the agent to obtain the recipe_id from the search tool, establishing a sequencing guideline. It does not explicitly exclude get_recipe_widget_data, but the context of needing full detail vs. widget data is implied. The photo guidance also tells the agent how to handle the response, adding practical usage direction.

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

• list_tagsA
  4.5/5.0
  Behavior4/5

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

  No annotations are present, so the description is the sole source of behavioral info. It discloses that it lists all tags with counts, indicating a read-only aggregate operation. It doesn't mention potential quirks like pagination, but for this simple listing the behavior is adequately conveyed.

  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 a single sentence, front-loaded with the verb and object, and contains no unnecessary words. Every word earns its place.

  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 the tool has no parameters and an output schema exists, the description fully covers what the tool does. It explicitly mentions the aggregate count detail, which is the core 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?

  There are zero parameters, so no parameter documentation is needed. The baseline of 4 applies as the schema imposes no burden and the description adds no confusion.

  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 'List' and clearly identifies the resource as 'all recipe tags/categories' with a distinct output detail (counts). It differentiates from sibling tools like get_recipe and search_recipes, which focus on individual recipes or searching.

  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 tool's purpose is self-evident for listing tags/categories, and the context of sibling tools implies this is the correct tool for a tag overview. However, it does not explicitly state exclusions or alternative selection guidance, so it stops short of full guidance.

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