mealie-mcp-ts

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.10
Disambiguation4/5
Most tools target distinct resources and actions clearly, with recipe CRUD, meal plans, shopping lists, foods, categories, tags, and user info separated. The three recipe creation methods (manual, URL, HTML) share intent but are differentiated by input source, and test_scrape_url adds a validation step. Shopping list item operations are distinct from adding a whole recipe's ingredients.
Naming Consistency5/5
All tool names use a consistent snake_case verb_noun pattern (list_, get_, create_, delete_, update_, upload_, add_, test_, parse_). Even longer names like create_recipe_from_url or get_todays_meal_plan follow the verb-first convention. There are no camelCase or mixed naming styles.
Tool Count4/5
27 tools is above the typical 'heavy' threshold, but the server covers many subdomains: recipes, meal plans, foods, shopping lists, categories, tags, user info, and URL scraping. Each tool has a defined role, though having three recipe creation variants inflates the count; a slightly leaner set could be achieved without losing functionality.
Completeness3/5
Core recipe management (CRUD plus image upload), meal plan basics, shopping list item operations, and URL scraping are well covered. However, there are notable gaps: no create_shopping_list or delete_shopping_list, no update/delete for categories or tags, no delete_food, and no update_meal_plan. These missing lifecycle operations could force users to rely on external tools or workarounds.
Average 3.8/5 across 27 of 27 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 only states the action ('add all ingredients') without explaining side effects such as whether ingredients are merged with existing list items, whether the list is cleared first, or what the response contains. It also does not mention permissions or idempotency.
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 two short sentences with no filler. The main purpose is front-loaded, and the optional quantity note is succinctly added. Every word contributes meaning.
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 the absence of annotations and output schema, the description is incomplete for a mutation tool. It does not clarify whether the operation appends or replaces existing shopping list items, how quantities are scaled, or what the function returns. While the schema covers parameters, the behavioral context is lacking.
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 description coverage is 100%, so the baseline is 3. The description's mention of 'Optionally specify quantity for multiple servings' adds a small semantic hint about recipeQuantity, but the schema already describes it as 'Number of servings/portions to add (default: 1)'. The description does not significantly exceed schema information.
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 function: 'Add all ingredients from a recipe to a shopping list.' It uses a specific verb ('add') and identifies both the source (recipe) and destination (shopping list). The phrase 'all ingredients' implicitly distinguishes it from sibling tools like add_shopping_list_item, which add a single item.
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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contrast with related tools such as add_shopping_list_item or create_recipe. The optional quantity note implies scaling use cases but does not constitute clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It states the action ('Add') but does not mention any side effects, required permissions, whether the list must exist, or what happens on duplicate items. This is a minimal mutation tool description with no behavioral depth.
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 two short sentences, front-loaded with the primary action, and every phrase adds value. It is appropriately concise without unnecessary elaboration.
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 annotations, no output schema, 6 parameters, and nested objects, the description is too sparse to be fully contextual. It does not mention that food and unit are nested objects requiring names, nor does it differentiate from add_recipe_to_shopping_list. The schema covers parameter details, but the description lacks operational context for a mutation tool.
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 description coverage is 100%, so the baseline is 3. The description adds some extra meaning by highlighting that quantity, unit, food, or a note can be provided, but it does not clarify relationships between parameters or the required shoppingListId beyond what the schema already states.
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 a specific verb ('Add') and resource ('item to a shopping list'), clearly indicating the tool's function. It also mentions flexible content types (quantity, unit, food, note), which helps distinguish it from add_recipe_to_shopping_list, though it does not explicitly name that alternative.
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 usage context is implied: it is for adding an ad-hoc item to a shopping list. However, there is no explicit guidance on when to use this tool versus add_recipe_to_shopping_list or update_shopping_list_item, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not disclose pagination behavior, search semantics, or response shape, despite having page/perPage/search parameters. The read-only nature is implied but not explicitly stated, and no details about what each tag includes are given.
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 two concise sentences, front-loaded with the main action. It avoids unnecessary verbosity and examples are relevant.
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 annotations and no output schema, the description is minimal for a tool with pagination/search parameters. It does not explain the paginated response structure, what fields are returned per tag, or how search interacts with listing. The agent may not know what to expect beyond raw data.
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 description coverage is 100%, with each parameter (page, search, perPage) having descriptive text including defaults. The tool description adds no parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 'List all recipe tags in Mealie' with specific verb and resource. It distinguishes from sibling tools like list_categories and list_recipes by explicitly focusing on recipe tags with example labels.
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 provides context ('Tags provide flexible labeling for recipes') but no explicit when-to-use guidance or exclusions compared to alternatives like list_categories. It does not mention when tags are preferred over categories or foods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden, but it only states 'Create a new food/ingredient' without mentioning return values, duplicate handling, permissions, or side effects.
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?
A single, directly worded sentence communicates the essential purpose without any filler or 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 create operation with fully documented parameters, this is minimally viable. However, the lack of annotations and output schema leaves room for additional context like response behavior or uniqueness constraints.
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 description coverage is 100% and each parameter already has a clear description. The tool description adds no extra semantic detail beyond what the schema provides.
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 'Create' and names the resource 'food/ingredient in Mealie', clearly distinguishing it from sibling tools like create_recipe or create_category.
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, nor any context about prerequisites or exclusions. It simply states the action without elaborating on typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action and parameter, but does not disclose permanence, idempotency, error behavior (e.g., deleting a non-existent ID), or any side effects.
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?
A single, clear sentence that is concise and front-loaded. Every word is purposeful and there is no filler.
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 one-parameter delete tool, the description covers the core function, but it lacks any context about expected outcomes or edge cases. Without annotations or an output schema, more detail would be helpful, making this minimally adequate.
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 coverage is 100%, and the description merely reiterates what the schema already states (that itemId is the ID of the meal plan entry). No additional semantic value is added.
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 a specific verb ('Delete') with a clear resource ('a meal plan entry') and method ('by its ID'). This unambiguously distinguishes it from sibling delete tools like delete_recipe and delete_shopping_list_item.
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 about when to use this tool versus alternatives. It does not mention related tools, prerequisites, or contexts where deletion might be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must reveal behavioral traits, but it only states that it creates an entry and optionally links a recipe. It does not disclose validation behavior for recipeId, duplicate handling, side effects, permissions, or the shape of a successful response.
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 two concise sentences with no filler. The action verb is front-loaded, and the optional linking behavior is mentioned without repetition.
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 5 parameters, no annotations, and no output schema, the description covers only the high-level action. It omits important operational context such as whether a linked recipe must exist, what happens if the date already has an entry, and what the caller receives downstream.
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 input schema provides 100% parameter descriptions, including enum values for entryType and defaults for title/text. The description adds only high-level context about date and optional recipe linking, not exceeding what the schema already conveys.
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 a specific verb ('Create'), resource ('meal plan entry'), and scope ('specific date'), clearly distinguishing it from sibling meal-plan tools like list_meal_plans and delete_meal_plan. It also clarifies the optional recipe linking, which sets it apart from recipe-only creation tools.
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 implies usage for adding a new meal plan entry but does not explicitly state when to use it over alternatives or provide exclusions. No cross-reference to related tools like list_meal_plans or create_recipe is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the image is uploaded as base64, with no mention of side effects (e.g., replacing an existing image), authentication requirements, file size limits, or error handling. This is minimal beyond what the schema already conveys.
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 two sentences with no redundant information. It front-loads the action and the required format, making it concise and easy to parse.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not mention response behavior, whether the upload replaces existing images, or any constraints. The agent is left without critical operational context.
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 100% parameter coverage with descriptions for all three fields. The description adds no extra meaning beyond saying the image is base64-encoded, which duplicates the schema. It does not clarify how slug relates to the recipe or how fileName is used.
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 action ('upload') and the resource ('an image for a recipe'), using specific language that distinguishes it from sibling tools like create_recipe or update_recipe. It also specifies the input format (base64), making the purpose unambiguous.
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 implies use when uploading an image for a recipe but does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or exclusions. The context is clear but lacks direct guidance on when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that originalText is parsed server-side and handles unknown units/foods automatically, which is non-obvious. However, it omits other behavioral details like return value or persistence effects, though mutation is implied by the tool name.
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 the primary purpose, then the most important parameter guidance. Every word earns its place with no redundancy.
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 create tool with 8 parameters and no output schema, the schema covers all parameter details, and the description adds the key usage nuance. Missing return-value info is a minor gap, but the description is sufficient for effective tool selection.
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%, so the baseline is 3. The description adds meaningful value by recommending originalText over structured fields, explaining that it is simpler and handles unknown units/foods. This goes beyond schema descriptions.
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 identifies the tool's purpose: creating a new recipe with name, ingredients, and instructions. It is specific and distinguishes from siblings like list_recipes or delete_recipe, though it does not explicitly contrast with create_recipe_from_url or update_recipe.
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 such as create_recipe_from_url or update_recipe. The suggestion to prefer originalText for ingredients is useful parameter-level guidance, but it does not address tool-selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'List all' but does not disclose pagination behavior, even though the input schema includes page and perPage parameters. The phrase 'all' could mislead an agent into thinking every shopping list is returned at once, while the default perPage=50 suggests otherwise. It also omits result format, sort order, or any operational details.
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 that is direct and front-loaded with the key action and resource. There is no filler or redundant content. Every word serves the purpose of identifying what the tool does.
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?
The tool is simple with only two optional parameters and no output schema, so the description could be minimal. However, the absence of an output schema and the lack of any mention of pagination in the description leaves an important gap. The agent may not know that the default page size is 50 or that results are paginated, which is especially relevant given the phrase 'all' in the description.
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 input schema already provides complete descriptions for both parameters (page and perPage) with defaults, accounting for 100% schema coverage. The description adds no additional parameter semantics, but since the schema is self-explanatory, the baseline of 3 is appropriate. No further compensation is needed.
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 action ('List all') and the resource ('shopping lists in Mealie'). It is distinct from sibling tools like list_recipes, list_foods, list_categories, and list_tags because it specifically targets shopping lists. The verb and resource are specific enough for an agent to select this tool when the goal is to retrieve shopping lists.
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 usage is implied: use it when you need to list shopping lists. However, there is no explicit guidance distinguishing it from alternatives such as get_shopping_list for retrieving a single list, or add_shopping_list_item for modifying lists. No exclusions or when-not-to-use instructions are provided, so the agent must infer the appropriate context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'Remove an item' without disclosing behaviors such as irreversibility, failure modes, permissions, or side effects. For a delete operation, this is a significant gap.
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, concise sentence that is front-loaded and free of unnecessary words. It fully communicates the tool's purpose without padding.
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 one well-documented parameter and no output schema, the description is largely complete. It lacks behavioral notes (like irreversibility), but the combination of description and schema is sufficient for an agent to invoke the tool 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 input schema provides 100% coverage for the single parameter with a clear description ('ID of the shopping list item to delete'). The tool description adds no additional semantic meaning beyond the schema, so the baseline score of 3 is appropriate.
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 'Remove an item from a shopping list' uses a specific verb ('Remove') and a specific resource ('item from a shopping list'), clearly distinguishing it from sibling tools like add_shopping_list_item and update_shopping_list_item. It is not a tautology and leaves no ambiguity about the tool's function.
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 implies the usage context (removing items from a shopping list) but does not explicitly state when to use it versus alternatives, mention prerequisites, or note any constraints. The intent is clear, but the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It states the core read-only behavior ('List all foods/ingredients') and the filtering capability, but does not disclose pagination behavior, default page size, or the exact semantics of search (e.g., substring vs exact match). This is adequate for a simple list operation but lacks depth.
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, concise sentence with no redundant words. It front-loads the primary action and resource ('List all foods/ingredients'), then adds the filtering capability, making it highly efficient and easily scannable.
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 list tool with no output schema, the description is functional but incomplete. It does not explain the return format, pagination behavior, or how search interacts with page/perPage. Given the lack of annotations, a short note on pagination or that results are paginated would improve completeness, but the tool is straightforward enough that the current description is minimally viable.
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 descriptions cover 100% of parameters, so the baseline is 3. The description adds no extra meaning beyond the schema; it only reiterates the 'search' parameter as a 'search term to filter foods', which is already stated in the schema. No additional parameter context is provided.
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 a specific verb ('List') and identifies the resource ('foods/ingredients in Mealie'), clearly differentiating it from sibling tools like list_recipes by the resource type. It also mentions the ability to filter by search term, which further clarifies its scope.
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 implies usage (when you need to list foods/ingredients) but provides no explicit guidance on when to use this tool versus alternatives like create_food or list_categories. It does not state any exclusions or prerequisites, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses the default 'returns all' behavior, which goes beyond the schema. However, it does not mention ordering, pagination, authentication requirements, or the exact return structure, leaving gaps in behavioral transparency.
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 two sentences with no redundant content. It states the primary action and the default case concisely, making it efficient and easy to parse.
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 two-parameter list tool, the description covers the essential filtering semantics. However, it does not mention sorting, whether dates are inclusive, or how this relates to sibling tools like get_todays_meal_plan, leaving room for more context. It is minimally viable but not fully complete.
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 description coverage is 100% for both parameters, so the baseline is 3. The description adds no additional parameter context beyond what the schema already states (date range, YYYY-MM-DD format), so the score remains at the baseline.
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 a specific verb ('List') and resource ('meal plan entries') and clearly scopes the action to a date range with a defined default. This distinguishes it from sibling tools like get_todays_meal_plan and list_recipes.
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 explains the date-range usage and the fallback behavior when no dates are provided, but it does not explicitly mention alternatives such as get_todays_meal_plan or when to prefer one over the other. Usage context is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only mentions that checked status can be used 'to mark items as purchased,' but it does not state whether updates are partial or full, what happens if the item does not exist, or if any permissions are required. This is a significant gap for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and lists key fields. It is appropriately sized with zero waste, earning a top score for conciseness.
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 update tool with no output schema, the description covers the core purpose but omits important context such as whether updates are partial (only fields provided are changed) and whether at least one mutable field must be specified beyond itemId. This leaves some ambiguity for an agent, so it is minimally viable but not rich.
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 already provides 100% parameter descriptions, so the baseline is 3. The description adds slight semantic value by explicitly linking 'checked' to 'mark items as purchased,' but overall it mostly restates the modifiable fields without deeper insight beyond the schema.
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 'Update a shopping list item' with a specific verb and resource, and enumerates the modifiable fields (quantity, note, checked status). This distinguishes it from sibling tools like add_shopping_list_item and delete_shopping_list_item, making the purpose unmistakable.
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 implies usage context: use when you need to modify an existing shopping list item's quantity, note, or checked status. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent can infer when this tool is appropriate versus adding/deleting items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the create action without mentioning write behavior, error handling, idempotency, or response format. This is inadequate for a mutation tool without annotation support.
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 two concise sentences. The first sentence clearly states the action, and the second adds useful context about the purpose of categories. There is no redundant or unnecessary wording.
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 one-parameter create tool, the description adequately covers the core purpose and context. It lacks mention of return values or behavior on duplicate names, but given the tool's simplicity and no output schema, the overall completeness is acceptable.
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 input schema has 100% coverage of the single 'name' parameter, including an example. The description adds no parameter-specific details beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 'Create a new recipe category in Mealie' with a specific verb and resource. It distinguishes from sibling tools like create_tag by specifying 'recipe category'.
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 clear context by explaining that categories help organize recipes into logical groups, implying when to use this tool. It does not explicitly exclude alternatives or mention prerequisites, but enough context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing details such as whether tag names must be unique, whether duplicates are allowed, or any side effects. This is a significant gap for a write operation.
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 consists of two short, front-loaded sentences. It is highly concise with no wasted words, and the first sentence delivers the core purpose immediately.
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 a single parameter and no output schema, the description provides sufficient context. It explains what tags are for and clearly identifies the action, though it omits any mention of the return value or edge cases like duplicate names.
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 already provides 100% coverage of the 'name' parameter with descriptions and examples. The tool description adds context by explaining that tags are flexible labeling, which gives additional semantic meaning to how the name parameter should be used.
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 action 'Create a new recipe tag' and specifies the resource ('tag') in the context of Mealie. This is a specific verb+resource pairing that distinguishes it from sibling tools like create_category and create_food.
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 implies usage by defining tags as 'flexible labeling for recipes,' but it does not explicitly state when to use this tool versus alternatives like create_category. There is no mention of exclusions or alternative tools, leaving the guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool returns full recipe details, which is helpful, but it does not address authentication requirements, error handling (e.g., 404 for invalid slug), or explicitly confirm a read-only operation, leaving some gaps.
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 two short sentences, front-loaded with the primary action, and contains no unnecessary words or redundancy. Every piece of information is relevant and contributes to clarity.
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 get-by-slug tool with no output schema, the description adequately communicates the return value ('full recipe details including ingredients and instructions'). It could mention what happens if the slug does not exist or how to obtain a slug, but given the simplicity and schema coverage, it is largely complete.
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 provides 100% coverage for the single parameter 'slug' with the description 'Recipe slug (unique identifier)'. The tool description adds little beyond referring to 'by its slug', so it meets the baseline for high schema coverage without adding significant param context.
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 function: 'Get a recipe by its slug.' It uses a specific verb (get), resource (recipe), and identifier (slug), and specifies the return content ('full recipe details including ingredients and instructions'), which distinguishes it from siblings like list_recipes or delete_recipe.
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 implies when to use the tool: when you have a recipe slug and need full details. It does not explicitly mention alternatives (e.g., 'use list_recipes to find slugs') or provide exclusion criteria, so guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It transparently indicates this is a read operation returning all meals for the day, but it does not disclose timezone handling, the structure of returned entries, or behavior when no meal plan exists. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The action and resource are front-loaded, and each sentence earns its place by adding relevant detail.
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 zero-parameter, read-only tool, the description is mostly complete: it states the resource, the scope (today), and the result (all meals). Lacking are return-value structure and timezone nuance, but the low complexity makes these minor 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?
The tool has zero parameters, and the schema confirms this with 100% coverage. The description correctly adds no redundant parameter details, meeting the baseline for a no-parameter tool.
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 gets 'today's meal plan entries' and specifies it returns all meals planned for the current day. This distinguishes it from siblings like list_meal_plans, which likely operates over all dates, and delete_meal_plan.
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 explicit guidance is given on when to use this tool versus alternatives like list_meal_plans. The phrase 'for the current day' implies the use case, but there is no direct comparison, exclusions, or mention of suitable contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the return format (summaries with name, slug, description, metadata) but does not mention pagination behavior, ordering, or any other behavioral aspects. The addition of return fields adds value, but the tool's behavior beyond that is underexplained.
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 two sentences, front-loaded with the tool's purpose and a concise listing of the return fields. Every sentence earns its place with no fluff or repetition.
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 list tool with two pagination parameters and no output schema, the description adequately covers purpose and return information. It could be more complete by explicitly mentioning pagination or any defaults, but the schema already documents those, so the description is sufficiently complete for the tool's simplicity.
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 description coverage is 100% for both page and perPage parameters, so the baseline is 3. The description adds no additional parameter semantics; it only describes the output, not the parameters, so it does not exceed the schema's documentation.
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 a specific verb and resource: 'List all recipes in Mealie' and distinguishes from siblings like get_recipe by stating it returns summaries with name, slug, description, and metadata. This clearly communicates the tool's scope and output.
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 implies usage by saying 'List all recipes' but does not explicitly alternate with get_recipe or other list tools. It provides clear context for what the tool does, but no exclusions or guidance on when to choose this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the responsibility for behavioral disclosure. The verb 'List' clearly implies a read-only operation, and no side effects are suggested or mentioned. However, the description adds minimal behavioral context beyond that—no mention of pagination limits, default ordering, or authentication requirements. For a basic list tool, this is 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?
The description is two sentences long: the first states the tool's purpose, and the second provides useful context about what categories are. There is no redundant information or filler. Every sentence earns its place.
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?
The tool is simple (list categories) with 3 optional parameters documented in the schema and no output schema. The description tells the reader what the tool does but does not explicitly describe the return format or any pagination behavior, though these are partially implied by the schema. Given the simplicity and the schema coverage, the description is minimally adequate but could be more complete by noting the response structure.
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 descriptions cover 100% of the parameters (page, search, perPage), so the description does not need to add parameter details. The description itself does not mention any parameters, but the schema already explains them adequately. Per the calibration rule, a baseline of 3 is appropriate when schema coverage is high.
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 specific action ('List all recipe categories in Mealie') with a clear resource. It distinguishes itself from sibling tools like list_recipes, list_foods, and list_tags by explicitly naming recipe categories as the target, making its purpose unambiguous.
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 clear context: this tool lists recipe categories, which are used to organize recipes. It implies when to use it (when you need recipe categories) but does not explicitly contrast it with alternatives or give exclusions. This is a simple listing operation where the need is self-evident, so the absence of explicit 'when not to use' is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the primary behavior (returns the list with all items) but does not mention error cases, permissions, or side effects (which are likely none). This is adequate but minimal, lacking richer 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?
Two short sentences, no fluff, front-loaded with the action. Every word 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 get-by-ID tool with one parameter and no output schema, the description covers purpose, parameter, and return value. It lacks details about not-found handling, but that is not critical for this low-complexity tool.
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 covers 100% of the parameter information with a clear description ('Shopping list ID'). The description merely restates 'by ID', adding no new semantics beyond the schema.
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 a specific verb 'Get' with a resource 'shopping list' and scope 'by ID'. It clearly distinguishes from sibling tools like list_shopping_lists and the various item mutation 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?
The description implies 'when you have a shopping list ID and want the full list' by stating 'by ID'. It does not explicitly mention alternatives like list_shopping_lists for listing all lists, but the context is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the parsing mechanism (Mealie or schema.org JSON-LD) and the context of use, but does not mention side effects, permissions, reversal, or return values. It provides some context beyond a bare 'create' verb, but not rich behavioral detail.
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 concise and well-structured: three sentences that front-load the core action, then provide usage context and parsing details. Every sentence earns its place with no redundancy or fluff.
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 tool with 3 params and no output schema, the description covers the purpose, usage, and parsing method completely. It clearly addresses the sibling alternative and the failure scenario. It doesn't explain return values or errors, but that's not strictly required given the simplicity and schema coverage.
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 description coverage is 100%, so the baseline is 3. The description does not add significant parameter semantics beyond the schema, but it reinforces that 'html' is raw HTML and the schema already documents sourceUrl and includeTags adequately. No extra meaning is needed.
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: 'Create a recipe from raw HTML that you fetched yourself.' It uses a specific verb and resource, and explicitly differentiates this tool from create_recipe_from_url by explaining when to use each. This distinguishes it from the sibling tool effectively.
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?
The description provides explicit usage guidance: 'Use this when create_recipe_from_url fails because the MCP server can't reach the site.' It even describes the workflow (fetch HTML yourself, pass it here) and the alternative, making it clear when to use this tool versus the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool scrapes data, supports most recipe sites with schema.org format, and reveals failure behavior ('returns success:false with diagnostic info'). It also advises to check diagnostics before retrying. Missing details like rate limits or auth requirements, but for a create operation with failure handling, this is strong additional transparency.
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 the core purpose, and zero filler. Every clause contributes value: the scraping method, structured data support, and failure fallback. This is a model of concise yet informative description.
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 moderate-complexity create tool with only two parameters and no output schema, the description covers the essential usage context: what it does, what it supports, and failure behavior. It also hints at a sibling for fallback. The lack of an output schema means return-value details would help, but the failure diagnostics mention partially compensates. Overall, the description is sufficiently complete for an agent to select and invoke the tool 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 schema already provides 100% coverage for both parameters, with clear descriptions for 'url' and 'includeTags'. The tool description adds context about scraping and structured data but does not elaborate on parameter-specific semantics beyond the schema. Baseline 3 is appropriate because the schema handles the heavy lifting.
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 and resource: 'Create a new recipe by scraping data from a URL.' It clearly distinguishes this tool from manual creation by specifying the scraping mechanism and mentions support for structured data (schema.org). The fallback reference to create_recipe further differentiates the tool from sibling 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?
The description provides clear context on when this tool is appropriate: for URLs with structured recipe data. It also gives an explicit fallback instruction ('falling back to create_recipe') on failure, which helps an agent decide between this and the manual sibling tool. However, it does not explicitly mention alternatives like test_scrape_url or create_recipe_from_html, leaving some ambiguity about which URL-based tool to choose in edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses the multi-step process: fetches the recipe, parses each ingredient, creates missing unit/food records, and saves structured ingredients back. This reveals the side effect of creating records, which is crucial since no annotations are provided.
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 sentences, each earning its place: the first states purpose and outcome, the second details the process and side effects, and the third gives usage guidance. There is no filler or redundancy.
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 single-parameter mutation tool with no output schema, the description covers the trigger, step-by-step behavior, side effects, and use case. It does not mention return values, but that is not critical for such an operation, leaving only a minor gap.
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 input schema already covers slug with a clear description ('Recipe slug whose ingredients should be parsed and structured') at 100% coverage. The description does not add extra parameter semantics beyond confirming the fetch-save behavior, so baseline 3 is fair.
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 a specific verb 'Re-parse' and clearly identifies the resource: 'ingredients for an existing recipe.' It also states the transformation goal ('proper quantity, unit, and food fields instead of free-text notes'), which distinguishes it from import or update 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?
Explicitly instructs to use it 'after importing a recipe from a URL whose ingredients came in as plain text,' providing a clear when-to-use context. It implies the tool is for existing recipes but does not explicitly list alternatives or when-not-to-use, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 two key behaviors: the tool does not create a recipe (no side effects) and returns success:false when the scraper cannot parse the site. This covers the primary behavioral expectations, though it does not specify the success response format in detail.
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 two concise sentences with no wasted words. The key purpose is front-loaded, and the behavioral note about success:false is added efficiently.
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 the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate. It conveys the purpose, side-effect-free nature, and the error condition. A perfect score would require explicit mention of the success return value, but this is a minor gap.
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 input schema already covers 100% of parameter meaning with the description 'URL of the recipe page to test scraping'. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
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: to test if a URL can be scraped for recipe data. It uses a specific verb ('test'), identifies the resource ('URL'), and distinguishes itself from sibling tools like 'create_recipe_from_url' by explicitly noting it does not create a recipe.
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?
Provides clear context for when to use the tool ('validating URLs before importing') and implies an alternative (actual importing, likely via create_recipe_from_url). However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of an explicit 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of disclosing behavior. It explicitly states that the action cannot be undone, which is a critical behavioral trait. It does not mention related side effects (e.g., on meal plans), but for a simple delete by slug, this is sufficient.
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 two concise sentences with no filler. The first sentence states the action and target, the second highlights an essential caveat. 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's simplicity (one parameter, no output schema, clear destructive action), the description is complete. It covers what the tool does, how to identify the recipe, and a critical warning. No additional context is needed for correct invocation.
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 description coverage is 100%: the 'slug' parameter is already described as 'Recipe slug to delete' in the input schema. The description adds no additional meaning beyond that, so the baseline score of 3 applies.
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 action with a specific verb ('Delete'), specifies the resource ('a recipe'), and identifies the key identifier ('its slug'). This distinguishes it from sibling tools like update_recipe or get_recipe, which serve different purposes.
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 implies the intended use—when a recipe needs to be permanently removed—and adds a clear warning about irreversibility. It does not explicitly contrast with update_recipe or list get_recipe, but the context is clear enough for an agent to select this tool for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses partial-update semantics and server-side parsing/normalization of ingredients, which are key behavioral traits beyond the schema. However, it omits error handling, auth, or response details.
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 the core operation, and no filler. The ingredient guidance 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?
The schema is rich and self-explanatory for parameters. The description covers the essential update behavior and ingredient best practice. The absence of return-value explanation is a minor gap given no output schema.
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%, so baseline is 3. The description adds value by explaining the tradeoff between originalText and structured ingredient input, and by clarifying partial updates affect all parameters.
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 "Update an existing recipe by slug," which is a specific verb+resource+identifier. It clearly distinguishes this from create_recipe, delete_recipe, and get_recipe.
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 clearly implies use for modifying existing recipes with "Update an existing recipe by slug" and explains the partial-update behavior ("Only provided fields will be updated"). It also gives parameter-level guidance (prefer originalText over structured), but doesn't explicitly name alternative tools like create_recipe for new recipes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It indicates a read-only operation ('Get information') and discloses the data returned (group and household). For a zero-parameter getter, this is adequate transparency; it could mention auth requirements, but these are implicit for an API user endpoint.
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 highly concise: two sentences that front-load the main action and then add a practical use case. Every word serves a purpose, with no redundancy or filler.
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 zero-parameter tool with no output schema, the description is complete. It explains what the tool returns (group and household) and why it might be used, covering all essential information for an agent to select and invoke it correctly.
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 tool has zero parameters, so the baseline is 4. The description does not need to elaborate on parameters, and no additional semantics are required beyond what is already clear from the schema (empty properties).
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 function: 'Get information about the current API user' and specifies included details (group and household). It distinguishes itself from sibling tools, none of which focus on user information, establishing a unique purpose.
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?
Provides a concrete use case: 'Useful for debugging permission issues when recipes or other items are not visible.' This is clear context for when to use the tool, though it does not explicitly mention when not to use it or alternatives, which are less relevant given no sibling tools cover user info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mealie-mcp-ts MCP server](https://glama.ai/mcp/servers/counterbeing/mealie-mcp-ts/badges/card.svg)](https://glama.ai/mcp/servers/counterbeing/mealie-mcp-ts)

Score Badge

Copy to your README.md:

[![mealie-mcp-ts MCP server](https://glama.ai/mcp/servers/counterbeing/mealie-mcp-ts/badges/score.svg)](https://glama.ai/mcp/servers/counterbeing/mealie-mcp-ts)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/counterbeing/mealie-mcp-ts'

If you have feedback or need assistance with the MCP directory API, please join our Discord server