Pantrist

Official

by Pantrist-dev

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct action and resource (pantry, shopping, recipes, week plan, lists). Overlaps like check_shopping_item vs delete_shopping_item are clearly differentiated by behavior. No ambiguity between tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_pantry_item, check_shopping_item, update_week_plan_day). Verbs and targets are uniformly structured.
Tool Count5/5
14 tools cover the main domains (pantry, shopping, recipes, week plan, lists) with a balanced number per domain. No tool feels redundant or missing for the apparent scope.
Completeness4/5
Core workflows are covered, but gaps exist: no delete pantry item, no create recipe, and only reduce stock (no increase). Week plan and shopping list are well covered. Minor gaps, not severely incomplete.
Average 4.6/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 5 community issues answered or closed in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on June 3, 2026
- 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.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares read-only behavior and describes return value structure including empty array case. No annotations provided, so description carries behavioral disclosure effectively.
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, each earning its place: first states purpose and read-only nature, second details return type and sibling alternatives. No wasted words.
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?
Covers purpose, return type, parameter usage, and alternatives. Minor omission of error cases or rate limits, but sufficient for a simple read-only list operation.
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 thorough explanation of listId (how to discover, mode-dependent optionality). Tool description references listId but adds no new semantics beyond 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?
Clearly states it lists all items in a pantry for a given listId, with read-only semantics. Explicitly differentiates from siblings like list_shopping_items and update_pantry_item.
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 explicit guidance on when to use this tool vs alternatives for shopping items, stock changes, and metadata updates. Also explains mode-dependent behavior of listId parameter.
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?
No annotations exist, so the description fully covers behavioral traits. It discloses read-only nature, return format (array of day objects with date and list), omission of days without entries, and the meaning of an empty array. Could mention idempotency or error handling but is already very helpful.
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 front-loaded with the main purpose, then return format, then disambiguation. Every sentence adds value, and there is no redundant or misleading information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately describes the return format and edge cases (empty array). It provides a complete picture for a read operation, though it could optionally mention error responses. Overall, it balances depth and brevity well.
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%, so the description does not need to add much about parameters. It briefly mentions the return format but does not elaborate on parameters beyond what the schema provides, which is acceptable given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists meal-plan entries between two dates, is read-only, and distinguishes it from the sibling tool 'update_week_plan_day' by specifying that one is for reading and the other for setting/clearing a single day.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (reading meal-plan entries for a date range) and when to use the alternative 'update_week_plan_day' for setting/clearing a single day. Also explains that an empty response means no entries, not an invalid range.
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 effectively discloses the destructive nature (full replacement, discarding previous entries), the return format { date, list }, and the clearing capability. It lacks details on authorization, error handling, or rate limits, but covers the main behavioral traits.
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 at four sentences, each adding value: main action, list behavior, clearing, return format, and alternatives. No superfluous content, and it is well-structured with front-loaded purpose.
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 no output schema and no annotations, the description adequately covers the operation, its effect, return value, and conditional parameters. It could mention error cases or validation, but for a tool of this complexity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaning beyond the schema by explaining that list is a full replacement, how to clear the day, and the conditional requirement for listId. This enhances the agent's understanding of parameter usage.
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 verb 'Replace' and the resource 'meal-plan entries for one day', and it distinguishes itself from sibling tools like get_week_plan and get_recipe by explicitly mentioning when to use them instead.
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 explicit guidance on the list parameter (full replacement, empty array to clear) and mentions alternative tools for reading. It also notes conditional behavior for listId (optional in stdio, required in HTTP). However, it does not explicitly state when not to use this tool.
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?
Discloses that name matching reuses existing articles or creates new ones, and mentions the return type ArticleDto. Missing idempotency or auth details but adequate given complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundancy. Could be slightly tighter but no waste.
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?
Covers essential behavior and return type despite no output schema. Does not explain error cases but sufficient for a create-tool.
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 covers all parameters (100%). Description adds useful defaults for amount and unitId, and how to discover unitId and listId, enhancing beyond 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 'Add a new item to the pantry by name' and distinguishes from siblings like reduce_pantry_amount, update_pantry_item, and add_shopping_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternatives, e.g., 'Use reduce_pantry_amount to change stock; use update_pantry_item to rename; use add_shopping_item for shopping list.'
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?
Declares 'Read-only' and lists the returned fields (RecipeDto with name, ingredients, etc.), filling the gap left by missing annotations. No other behaviors (rate limits, auth) are mentioned, but the core safety trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, each sentence earns its place. No wasted words, clear and efficient structure.
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?
No output schema, but the description fully describes the return structure (fields of RecipeDto). Combined with clear input guidance and context from siblings, the description is complete for the tool's complexity.
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 already explains the parameter's source. The description reinforces this but adds no new meaning beyond the schema, so baseline 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 'Get a single recipe by its uuid' – a specific verb and resource. It distinguishes from siblings by referencing 'search_recipes' for discovery and 'delete_recipe' for removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using 'search_recipes' to find uuids before calling this tool, and points to 'delete_recipe' for deletions. Provides clear when-to-use and when-not-to-use guidance.
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 declares the tool is read-only and describes the return structure, which is sufficient for a simple list retrieval tool. No negative behaviors or prerequisites are mentioned, but none are needed.
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, no wasted words. The first sentence establishes purpose, the second provides actionable details. Information is front-loaded and easy to parse.
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 zero parameters and no output schema, the description fully covers what the tool does, what it returns, and how to use the results. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is effectively 100%. The description adds value by explaining the return object structure (uuid, name, role) and how to use the uuid subsequently. Baseline is 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists shopping lists/pantries for the authenticated user, specifies it's read-only, and details the return fields (uuid, name, role). This distinguishes it from sibling tools that operate on individual items or recipes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions using the returned uuid as listId for other tools, providing clear usage context. However, it does not explicitly state when not to use this tool or name alternatives, but the purpose is sufficiently clear from the sibling tool names.
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?
No annotations provided, so description carries full burden. It explains article matching logic (reuse vs create), and returns ArticleDto. It also mentions listId as optional in stdio mode. Minor lack: doesn't specify which shopping list is used if listId omitted, but still adequate.
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 with no redundancy. The first sentence states the core action, the second adds behavioral nuance, the third provides usage guidance with sibling references. Every 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?
Given no output schema, the description mentions the return type 'ArticleDto', which is sufficient. Input parameters fully covered. Alternative tools referenced. Only minor gap: no explanation of what the 'shopping list' is, but context implies the user's main list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining case-insensitive matching for name and the context-dependent optionality of listId. This goes beyond what the schema descriptions alone provide.
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 starts with a clear verb-resource pair: 'Add an item to the shopping list by name.' It distinguishes from siblings by naming specific alternatives like add_pantry_item and check_shopping_item.
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 explicitly states when to use this tool vs alternatives: 'To add directly to the pantry instead use add_pantry_item; to mark an existing shopping item bought use check_shopping_item.' It also clarifies listId optionality across modes.
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?
No annotations provided, so description carries full burden. Discloses mutation, return type ('returns the updated row'), and three possible behaviors (markDone, removeOnCheck, moveOnCheck) based on list settings. Could mention idempotency or error cases, but overall sufficiently transparent.
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?
Four sentences: purpose, effects, mutation/return, alternatives. Front-loaded and efficient with no unnecessary words.
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 complexity (3 behaviors, mutation, no output schema), description covers key aspects: behavior variants, alternatives, return type. Could mention error handling or prerequisites, but remains adequate for selection and invocation.
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 description coverage is 100%, baseline 3. Description adds meaning beyond schema by specifying where to get itemId ('from list_shopping_items[].uuid or add_shopping_item') and explaining listId optionality and fallback to env var. Adds useful 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?
Describes checking off a shopping-list item with specific verb and resource. Distinguishes from siblings delete_shopping_item and reduce_pantry_amount by explaining when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs alternatives: 'To unconditionally remove regardless of list settings use delete_shopping_item; for stock changes on a pantry item use reduce_pantry_amount.' Also explains conditional behavior based on list settings.
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?
No annotations are provided, so the description carries full burden. It declares read-only, describes the return type (array of ArticleDto objects) and the empty array edge case, and explains the listId parameter behavior in different modes (stdio vs HTTP). Missing details on auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded: first sentence states purpose and read-only nature; second sentence provides sibling references and return type. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers purpose, usage, parameter details, return type, edge case (empty array), and sibling tool references. It is complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for listId. The description adds significant context: how to discover the list ID via 'list_lists', and the fallback behavior in stdio mode (env var) vs HTTP mode (required). This goes 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 'list' and resource 'shopping items' with a required 'listId'. It clearly distinguishes from siblings like 'list_pantry_items' and 'add_shopping_item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides alternatives: for pantry items use 'list_pantry_items'; to add items use 'add_shopping_item'. It also indicates read-only behavior, but does not explicitly state when not to use the tool.
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?
No annotations provided, so description carries full burden. It discloses mutation, return of updated DTO, autoRestock side effect, and that positive values work for restocking. Lacks permission or reversibility details but covers key behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then details and sibling differentiation. No wasted words, efficient and clear structure.
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?
No output schema but description states return type. Parameters fully explained, sibling context provided, side effects documented. Complete for a tool of this complexity.
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%, baseline 3. Description adds extra context: amountChange clarifies positive works for restocking, autoRestock explains condition and default, listId distinguishes stdio vs HTTP modes. Adds meaningful value beyond 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 it changes stock by a delta, distinguishes from 'add_pantry_item' (create) and 'update_pantry_item' (metadata), and specifies the exact resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use alternatives (add_pantry_item for creation, update_pantry_item for metadata) and explains the autoRestock side effect, providing clear when-to-use and when-not-to-use guidance.
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 declares the tool is read-only, paginated, and specifies the return shape. While no annotations are provided, it could be more explicit about page size limits or ordering, but it adequately covers core behavioral traits.
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 pack all essential information without wasted words: purpose, return format, and sibling references.
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 no output schema, the description compensates by specifying the return structure. It covers all parameters and pagination. Could mention error handling or default page size, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant detail: free-text matching behavior (case-insensitive, fields searched), category OR-combination, and currentPage defaults and fixed page size.
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 searches user recipes by free-text and category filters, differentiating itself from sibling tools like get_recipe and 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions when to use search_recipes versus alternatives (get_recipe for single lookup, delete_recipe for deletion), providing clear context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavioral traits: unconditional irreversible delete, error behavior (403 passed verbatim), and recommendation to confirm ownership. Transparent about all key aspects.
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 with no redundancy. First sentence states core action, second explains error handling, third gives actionable tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description adequately covers behavior, error conditions, and precondition. Complete for a simple delete operation without needing return value details.
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?
Single parameter recipeId with 100% schema description coverage. Description reinforces schema info and adds context about hard-delete permanence, going beyond baseline 3.
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?
Clear verb 'Delete' with specific resource 'a recipe you own' and description of unconditional and irreversible action. Distinct from sibling tools like delete_shopping_item.
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?
Explicit guidance to preview with get_recipe before deleting, along with note about 403 error for unauthorized attempts. Provides clear when-to-use and precaution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that the tool internally fetches the current `ArticleDto`, performs a PUT merge, makes two API calls per invocation, and returns the updated `ArticleDto`. This covers side effects, idempotency, and round-trip behavior comprehensively.
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 tightly focused sentences. The first sentence defines purpose and scope; the second provides behavioral context, alternative tool, and expected return. Every word serves a purpose, no redundancy.
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 metadata update tool with 7 parameters, the description covers all needed context: what it does, when to use, behavioral details, and return type. No output schema exists, but the description mentions the returned `ArticleDto`. No gaps for effective agent invocation.
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?
All 7 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds unique value by explaining the merge behavior and noting that listId is optional only in stdio mode, which enriches understanding 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 the verb 'update', resource 'pantry item', and scope 'metadata' (rename, change unit, category, brand, notes). It also explicitly distinguishes from the sibling tool `reduce_pantry_amount` for stock changes, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use `reduce_pantry_amount` for stock changes — this tool only touches metadata.' It also explains that only passed fields change, others round-trip unchanged, telling the agent when to use this versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: 'unconditionally and irreversibly', 'no soft-delete', 'not affected by list removeOnCheck setting', 'row is gone after call returns'. Returns a confirmation string.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Highly efficient.
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?
No output schema, but describes return value as confirmation string. For a simple delete tool, all necessary context provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100%, but description adds critical context: itemId warning about permanence, listId source and optionality explanation.
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?
Description clearly states 'Remove an item from the shopping list' with specific verb and resource, and explicitly distinguishes from sibling tool check_shopping_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (hard delete) and when to use alternative (check_shopping_item for list-setting-dependent behavior). Also notes unconditional and irreversible nature.
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:

[![pantrist-mcp MCP server](https://glama.ai/mcp/servers/Pantrist-dev/pantrist-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Pantrist-dev/pantrist-mcp)

Score Badge

Copy to your README.md:

[![pantrist-mcp MCP server](https://glama.ai/mcp/servers/Pantrist-dev/pantrist-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Pantrist-dev/pantrist-mcp)

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/Pantrist-dev/pantrist-mcp'

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