Raley

by johnzfitch

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes: search/add/remove/cart handle core shopping, while deals/offers, price, plan, orders, favorites, and knowledge cover different aspects. A few pairs overlap conceptually (search vs search_batch, add vs add_plan, deals vs offers), but descriptions clarify when to use each.
Naming Consistency2/5
Tool names mix single-word nouns (deals, cart, offers, store, memory, knowledge) with imperative verbs (search, add, remove, plan) and compound verb_noun forms (cart_diff, add_plan, search_batch). There is no consistent naming convention, which makes the set feel less predictable.
Tool Count4/5
With 18 tools, the server is on the heavier side but each tool addresses a specific need in the grocery shopping workflow. The count is justified given the breadth of features (product search, cart management, deals, price history, planning, memory, and account functions).
Completeness4/5
The tool surface covers core grocery tasks well: searching, adding/removing/viewing cart, bulk operations, deal retrieval, price history, order history, favorites, store selection, and user preferences. Minor gaps exist (e.g., no direct quantity update tool, no checkout/order placement), but they are workable and the domain is well represented.
Average 3.2/5 across 18 of 18 tools scored. Lowest: 1.5/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 The Unlicense.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It reveals nothing about side effects, permissions, output format, or the meaning of parameters like save_to_file. The agent has no idea if this operation is safe to invoke or what consequences it may have.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely brief, this is under-specification rather than conciseness. The single phrase 'Order history.' does not provide enough substance to be considered efficient; it is merely a placeholder that omits all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and no annotations. The description is far too shallow to cover the behavioral and semantic complexity, leaving the agent without essential information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the four parameters (days, limit, save_to_file, summary_only). The description adds no meaning beyond what bare parameter names convey, and even those names are ambiguous without further elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Order history.' is a noun phrase that essentially restates the tool name 'orders' without any verb or action. It does not specify whether the tool fetches, lists, updates, or deletes order history, and provides no differentiation from sibling tools like 'deals' or 'cart'.
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 offers no guidance on when to use this tool versus alternatives. There are no scenarios, prerequisites, or exclusions mentioned, leaving the agent without any contextual cues for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It only lists action names without explaining their effects, side effects, or whether any are destructive. 'clip_all' is ambiguous and potentially destructive, but nothing is clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. 'Coupons.' is a noun fragment, and the action list adds little context. It could be summarized in one proper sentence, but it lacks essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description should explain the tool's behavior and parameters. It doesn't describe return values, effects, or how actions differ. This is completely inadequate for a multi-action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for any parameters (0% coverage). The description only repeats the action enum, offering no explanation for 'cat', 'limit', 'save_to_file', or even what each action does. It fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Coupons. action: list|clip_all|sync' indicates the tool deals with coupons and lists three possible actions, but does not explicitly state what the tool does (e.g., 'lists coupons'). It provides a resource and an action enum but lacks a clear verb-oriented description, making it vague.
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 information is given about when to use this tool over siblings like 'deals' or 'offers'. There is no mention of prerequisites, contexts, or alternatives.
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 discloses that clearing cache is possible and gives a condition for it, but it does not mention whether searches are read-only, what side effects occur, or any auth/rate limits. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but the first sentence is a comma-separated list of actions that is somewhat cryptic and lacks clear structure. It is not redundant or verbose, but the clarity suffers from the abrupt listing of actions.
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?
The tool has multiple behaviors (price history, search, cache clear) with no output schema and no annotations. The description does not explain return values, how the different modes interact, or provide enough context for correct invocation in varied scenarios. It is incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with q and sku lacking descriptions. The description adds meaning to 'sku' (price history by SKU) and 'clear' (cache clearing), and indirectly hints that 'q' relates to searching the local DB. However, it does not clarify the exact format or relationship between q and sku, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists three separate capabilities (price history by SKU, search local DB, clear cache) without a clear primary verb or focus. It identifies a resource (price history) but lacks a specific action verb and does not distinguish it from siblings like 'search' or 'offers'.
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 only usage guidance is 'Use clear=true when user changes store/delivery location,' which addresses a specific parameter condition but does not explain when to use this tool over alternatives such as search or offers. No clear when-to-use or when-not-to-use guidance 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?
With no annotations provided, the description relies entirely on its own content for behavioral disclosure. It only states the data origin without mentioning any side effects, the meaning of 'sync' (refresh), or the nature of 'stats', leaving the agent uninformed about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that quickly conveys the basic purpose. However, it lacks any structural breakdown or additional detail that would make the sentence more informative, making it adequately concise but not exemplary.
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 lack of annotations and output schema, the description must carry more weight, but it fails to explain the varying behaviors of the 'type' parameter or any return format. The tool appears too complex for such a brief description, leaving the agent with significant unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'type' with an enum and a short description, but 'limit' is left undocumented. The description adds no explanation for either parameter, especially 'limit', so it does not compensate for the schema's gaps.
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 indicates that the tool provides purchase history from the 'previously purchased' API, specifying both the resource and the source. However, it does not distinguish this from sibling tools like 'orders' or 'deals', which may serve a similar purpose.
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 gives no guidance on when to use this tool versus alternatives or how to choose among the 'type' values (products, brands, stats, sync). No context or exclusions are provided, leaving the agent without direction for appropriate usage.
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 burden of behavioral disclosure. It discloses that the tool returns a single 'best match' with specific fields, which is a meaningful behavioral trait. However, it does not mention potential side effects, authentication needs, or matching behavior (e.g., fuzzy vs exact), leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one for purpose and one for output. Every word serves a purpose, and it is not a tautology. However, it could be slightly more structured by directly tying output fields to the tool's behavior.
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?
The tool has 3 parameters and no output schema, so the description should cover parameter semantics and usage constraints. It only covers purpose and output briefly, leaving the agent uninformed about required inputs and edge cases. This is insufficient for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It fails to explain the meaning or expected values of 'q', 'diet', or 'sale'. The agent would have to infer these from parameter names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Search products') and the expected output ('best match with SKU, price, unit pricing'), which distinguishes it from generic tools. However, it does not explicitly contrast with sibling tools like 'search_batch' or 'offers', so it lacks sibling differentiation.
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?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, without mentioning appropriate contexts, exclusions, or comparisons to sibling tools like 'deals' or 'price'.
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?
There are no annotations, so the description must fully disclose behavioral traits. It only states the action and input requirements, with no mention of side effects (e.g., whether existing cart items are updated or replaced), idempotency, authentication, or what the response contains. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with only two sentences and no filler. The fragment 'Need SKU and price_cents from search' is terse and actionable, though slightly informal. It earns a high conciseness score for its compactness, though it sacrifices completeness.
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 tool has no annotations, no output schema, and three parameters, the description is far too minimal. It doesn't explain what the function returns, how errors are handled, how 'qty' interacts with the cart, or any side effects. The mention of search is helpful, but overall the description is insufficient for an agent to confidently use the tool in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining all parameters. It explicitly mentions SKU and price_cents (mapped to 'cents'), which adds meaning to those two properties. However, the optional 'qty' parameter is completely unexplained, leaving a gap for an important aspect of the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a verb and resource: 'Add to cart.' It also mentions the prerequisite inputs (SKU and price_cents), which helps differentiate it from other cart-related tools like 'remove' or 'cart_diff'. However, it doesn't explicitly state what kind of item is added (e.g., product, offer), leaving some ambiguity.
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: after a search, since it says 'Need SKU and price_cents from search.' This gives a clear context. However, it does not provide explicit comparisons or exclusions relative to sibling tools like 'add_plan' or 'cart_diff', so the usage guidance is somewhat implicit rather than directive.
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 full burden. It discloses that it does not add to cart, which is a useful behavioral trait, but it doesn't disclose other side effects, whether it reads or writes elsewhere, or what it returns. The tool likely creates a plan (given sibling 'add_plan'), but no side effects are mentioned. This is insufficient 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 short sentences, front-loaded with the core action and a key constraint. No filler words; every word contributes. It's appropriately concise.
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 4 parameters, no schema descriptions, no annotations, and no output schema, the description is far too sparse. It doesn't explain parameter meanings, return values, or usage scenarios, leaving the agent to guess. It covers only the most basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 4 parameters with zero descriptions, and the tool description mentions none of them. 'Items' is inferable as the grocery list, but budget, save_to_file, and summary_only are entirely unexplained. The description adds no parameter semantics over the bare schema.
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 states 'Parse grocery list, find matches. Does not add to cart.' This names a specific verb (parse/find) and resource (grocery list), with a scoping note ('does not add to cart') that differentiates from cart-modifying sibling tools. However, it doesn't explicitly distinguish from sibling 'search' or 'deals', so it's clear but not fully differentiated.
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?
Usage is implied: it's for parsing a grocery list and finding matches, and it clarifies it won't add to cart. But it doesn't explicitly say when to use this over alternatives like 'search' or 'cart_diff', and doesn't mention conditions or exclusions beyond the cart note. Thus, implicit guidance only.
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. 'View' implies a read-only operation, and mentioning 'save_to_file' hints at a potential side effect, but the description does not elaborate on the nature or consequences of this option. Additional details are lacking, so transparency is only partially provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences and front-loaded purpose. The second sentence is somewhat boilerplate but not wasteful, though it could have been more informative.
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 simple tool with three optional parameters and no output schema, the description is insufficiently complete. It does not explain what the returned cart view contains, how parameters affect behavior, or any side effects of saving to a file, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. However, it merely lists the parameter names ('summary_only, save_to_file, and limit') without explaining their meaning or behavior. This adds no semantic value beyond the schema's property names and types.
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 'View cart' with a specific verb and resource, clearly distinguishing it from siblings like cart_diff, add, and remove. The purpose is immediately understandable and unambiguous.
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. It does not mention any prerequisites, exclusions, or comparisons with other tools, leaving the agent without context for selection.
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 discloses that memory persists across sessions, but does not explain write semantics (overwrite vs. append), return values, or side effects of actions like 'set' and 'note'. This leaves significant behavioral ambiguity.
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 verb 'Read or write', and every phrase adds value. It is concise and free of filler.
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?
Without annotations or an output schema, the description must explain behavior sufficiently. It fails to cover the three actions, the purpose of 'limit', or what get returns. For a 5-parameter tool with nuanced actions, this is incomplete.
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 80%, so the schema already documents most parameters. The description adds context about memory content (T1D config, notes, preferences) but does not clarify the meaning of the 'action' enum or the distinction between 'set' and 'note'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads or writes shopping memory, specifying the domain (T1D config, notes, preferences) and persistence across sessions. It distinguishes itself from cart/deals tools but does not explicitly differentiate from similar storage tools like 'knowledge' or 'read_saved'.
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 persistent memory storage but gives no explicit guidance on when to use this tool versus alternatives such as 'knowledge' or 'store'. There are no exclusionary statements or alternative tool references.
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 for behavioral disclosure. It only states the basic action ('remove from cart') but does not disclose important behaviors such as whether the operation is idempotent, what happens if the SKU is not found, or whether it removes all quantities or just one. 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: 'Remove from cart by SKU.' It has zero wasted words and clearly communicates the action and key parameter. It is appropriately concise for a tool with only one parameter.
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 one required parameter and no output schema or annotations. The description covers the core purpose adequately, but it misses some context that would improve completeness, such as whether the operation is destructive irreversibly or how it handles missing SKUs. Still, it is minimally viable for a basic cart removal action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'sku' with no description. The description mentions 'by SKU', which only restates the parameter name and confirms its role. It does not add meaningful details about the expected format, validation, or behavior with invalid input. Given the 0% schema description coverage, the description compensates minimally.
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 from cart by SKU' uses a specific verb 'remove' with a clear resource ('cart') and the key input method ('by SKU'). It clearly distinguishes from sibling tools like 'add' (the opposite action) and 'cart' (viewing the cart).
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 by the straightforward action: use this when you want to remove an item from the cart by its SKU. However, there is no explicit guidance about when not to use this tool or any mention of alternatives, such as 'add' or 'cart_diff'.
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 the full burden of behavioral disclosure. It adds the useful fact that prices/availability depend on the store, but it does not disclose side effects of changing the delivery address, persistence of changes, or any required permissions. The description is too sparse for a tool with mutating actions like 'set'.
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 primary function, and avoids extraneous detail. Every sentence earns its place, with the second sentence providing important context about the impact of the store.
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?
The tool has four distinct actions (info, set, lookup, addresses) and a nested address object, yet the description offers only a high-level summary. Without an output schema and with no annotations, the description should provide more detail on what each action returns and what side effects occur, but it does not.
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 a small amount of context by linking store/address to pricing and availability, but it does not elaborate on the parameters themselves. The schema already documents each parameter, so additional value is minimal.
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: 'View/change fulfillment store and delivery address.' It uses specific verbs (view/change) and a specific resource (fulfillment store and delivery address), distinguishing it from sibling tools like cart, price, and orders which deal with different concerns.
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 context by noting that 'Prices and availability depend on the fulfillment store,' suggesting this tool is relevant when store context matters. However, it does not explicitly state when to prefer this tool over siblings or when not to use it, so guidance remains implied rather than explicit.
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 transparency. It discloses that the tool uses clipped coupons, sale prices, and price history, and that results are time-bound to 'this week.' However, it does not mention read-only behavior, authentication needs, or how the dependency on 'offers sync' affects results.
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 value proposition and ending with a clear operational note. There is no unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description explains the core behavior and a dependency but omits return format, parameter semantics, and potential side effects. For a simple list tool, it is adequately complete but leaves gaps that could affect correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; gi_filter is described in the schema, but limit is undocumented. The description does not clarify the meaning of 'limit' or how it interacts with the listed data sources. The mention of 'price history' does not relate to parameters.
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: showing best-value items this week based on clipped coupons, sale prices, and price history. It distinguishes itself from the sibling 'offers' tool by emphasizing these unique data sources, though it lacks an explicit verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit usage instruction: 'Run after offers sync.' This gives a clear temporal dependency and implies when to use it. It does not mention alternatives or exclusions, but the sequencing guidance is valuable.
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 must disclose behavior, but it only explains input format. It does not mention side effects (e.g., whether items are appended or replace existing cart), prerequisites, or validation behavior. This is a gap for a mutation-like 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 is two short sentences, front-loads the action ('Bulk add items to cart'), and provides a concrete format example in the second sentence. Zero 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?
For a simple single-parameter tool with no output schema, the description sufficiently explains input format and overall intent. Sibling differentiation is weak, but the simplicity of the tool makes the description mostly 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 coverage is 100% and the parameter description matches the tool description. The description adds no meaning beyond the schema's own 'items' string format, 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 states a specific verb ('Bulk add') and resource ('items to cart'), clearly distinguishing it from siblings like 'remove' or 'cart'. The format details ('sku:cents' pairs) reinforce the tool's purpose.
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 word 'Bulk' implies use for multiple items, but no explicit when-to-use or alternatives are provided. Sibling tools like 'add' and 'cart' suggest different use cases, yet the description does not guide the agent on choosing between them.
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 disclosing behavioral traits. It explains that the tool shows missing/extra/quantity mismatches, but does not explicitly state that it is read-only or non-mutating, nor does it cover edge cases or error handling. This is partial disclosure—some behavioral context is given, but not a full safety profile.
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 states the purpose and the key outputs with zero wasted words. It is exemplary in conciseness.
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 parameter and no output schema, the description covers the essential aspects: what it compares, what it reports, and the input format (implied via schema). It lacks explicit mutation status, but the comparison context makes it reasonably 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%, so the baseline is 3. The tool description adds little beyond the schema, just reinforcing that expected SKUs and quantity pairs are involved. The schema already documents the comma-separated format and sku:qty pairs, so the description doesn't add notable extra meaning.
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 ('Compare') and clearly identifies the resource (expected SKUs vs. actual cart) and the output categories (missing, extra, quantity mismatches). This distinguishes it from sibling tools like 'cart', 'add', and 'remove'.
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 establishes a clear context for when to use the tool: whenever you need to verify that the cart matches an expected list of SKUs. It does not explicitly mention alternatives or exclusions, but the comparison purpose is evident, and no exclusions are needed for this straightforward tool.
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 burden of disclosure. It does reveal one key behavioral trait: 'Returns best match per query,' which informs the user of the output approach. However, it does not mention potential limitations (e.g., error handling, rate limits, ordering of results) or confirm safety (read-only implication), so there are 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 sentences, front-loaded with the action and resource, and every word adds value. There is no fluff or repetition of schema information; it efficiently states purpose, result, and usage guidance in a compact form.
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 a single parameter and no output schema, the description provides enough context: it states the batch nature, the per-query result behavior, and a reason to use it over an alternative. It does not describe the exact structure of the returned matches, but this is not necessary for such a simple 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 coverage is 100%, with the 'queries' parameter already described as 'List of product queries (max 15).' The description adds the semantic of searching multiple products at once, but this is largely implicit in the parameter type and tool name. It does not add format details beyond the schema, so the baseline 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 uses the specific verb 'Search' and resource 'multiple products,' clearly distinguishing itself from the sibling 'search' tool by noting it processes multiple queries at once. The phrase 'Search multiple products at once' is a clear, specific action, and 'Returns best match per query' clarifies the result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use instead of calling search N times,' which directly contrasts with the alternative 'search' tool and gives clear context for when to prefer this batch version. However, it does not mention exclusions or when to use the single search tool instead, so it stops short of full 5.
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 full burden. It discloses the search action and domain, but does not explicitly state that the tool is read-only, nor does it mention any limitations, edge cases, or response behavior. Since it is a search tool, the core behavior is implied, but transparency is only 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?
The description is two sentences, front-loaded with the primary action and examples, followed by a concise usage pointer. Every word contributes to understanding, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with 4 params and no output schema, the description gives sufficient context for tool selection and invocation. It lacks details on return format and limit behavior, but the combination of purpose, usage guidance, and schema descriptions makes it reasonably 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 75% (q, book, heading have descriptions; limit does not). The description adds valuable domain-specific vocabulary (GI tables, insulin math, carb counting) that helps the agent construct effective search terms for q, but does not clarify limit usage or other parameter nuances.
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 'Search installed T1D reference books' with specific topics (GI tables, insulin math, carb counting, recipes, meal planning), which precisely identifies the resource and differentiates it from generic sibling tools like 'search' or 'search_batch'.
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 when-to-use guidance: 'Use when the user asks about nutrition science, insulin timing, or needs recipe ideas.' While it does not name alternative tools, the context strongly implies the intended use case and distinguishes it from general search.
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?
Without annotations, the description carries the full burden. It discloses the source of files (previously saved via save_to_file=true), the return format (JSON contents), and implies a read-only nature. It does not cover error behavior for missing files, but for a simple read operation this is acceptable.
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 action and resource, and contains no redundant words. The structure is clean and immediately informative.
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 parameter and no output schema, the description covers purpose, source, and return format. It lacks explicit mention of edge cases like file-not-found behavior, but is otherwise complete for its 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?
The schema already fully documents the parameter 'filename' with examples and prefix support (100% coverage). The description adds no further 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 reads a previously saved result file and returns its JSON contents. The reference to 'save_to_file=true' distinguishes it from sibling tools like 'memory' or 'search' and ties it to the saving mechanism.
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 for when to use the tool: when you need to access a result file saved with save_to_file=true. It does not explicitly mention alternatives or exclusions, but the context effectively implies the tool's niche.
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 for behavioral disclosure. It explicitly states that no cookie values are exposed, providing a useful safety guardrail. It also implies a read-only operation through the verb 'check', giving basic transparency about 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?
The description is a single, concise sentence that immediately conveys the tool's purpose. It includes a parenthetical safety note that adds important context without unnecessary length.
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 (zero parameters, no output schema, no annotations), the description is nearly complete. It covers the core function and a key behavioral safeguard. The only minor gap is not specifying the return format (e.g., boolean or object), but this is acceptable for a simple status check.
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 for this dimension is 4 per the rubric. The description does not need to add parameter semantics since there are none, and the input schema correctly reflects this with an empty properties object.
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 with a specific verb ('Check') and resource ('authentication status'). It is easily distinguished from sibling tools like deals, cart_diff, and search, none of which relate to authentication.
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 tool should be used when the agent needs to determine if a user is authenticated. There are no explicit alternatives or exclusions, but the purpose is clear enough for the user to select it in appropriate contexts. No sibling tools offer similar functionality, so alternate guidance is not critical.
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:

[![raley-bot MCP server](https://glama.ai/mcp/servers/johnzfitch/raley-bot/badges/card.svg)](https://glama.ai/mcp/servers/johnzfitch/raley-bot)

Score Badge

Copy to your README.md:

[![raley-bot MCP server](https://glama.ai/mcp/servers/johnzfitch/raley-bot/badges/score.svg)](https://glama.ai/mcp/servers/johnzfitch/raley-bot)

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/johnzfitch/raley-bot'

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