blinkit-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action or resource (e.g., add_to_cart vs. remove_from_cart, search vs. pick_best). There is minimal overlap, and descriptions clearly differentiate similar tools.
Naming Consistency5/5
All tools follow a consistent 'blinkit_verb_noun' pattern in snake_case, making the tool surface predictable and easy to navigate.
Tool Count4/5
With 25 tools, the set is slightly larger than the ideal range but justifiable for a full-featured e-commerce MCP server covering login, location, cart, search, ordering, and payment.
Completeness4/5
The surface covers most lifecycle stages (login, search, cart, checkout, payment, staples), but lacks explicit order cancellation or address update during checkout, which are minor gaps.
Average 3.6/5 across 25 of 25 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only nature, required user state, or rate limits. For a suggestion tool, more behavioral context would help, e.g., whether it depends on location or cart contents.
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 extremely concise with one sentence, no unnecessary words. However, it may be too succinct for full clarity, but conciseness is generally positive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It does not explain expected output (e.g., list of strings, objects), error handling, or behavior for empty or invalid queries. For a simple tool, it may be borderline adequate, but missing details reduce completeness.
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 single parameter 'query' is only described as 'partial query' without format, constraints, or examples. Schema description coverage is 0%, so the description should provide more detail (e.g., minimum length, encoding) but fails to do so.
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 provides 'Typeahead suggestions for a partial query,' indicating the purpose of autocomplete functionality. It implies a verb (suggest) and resource (query suggestions), and it distinguishes from siblings like blinkit_search which handles full queries.
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 like blinkit_search or blinkit_recommendations. The description implies use during partial query entry but lacks explicit when-not or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'Add or update' but does not explain idempotency, overwrite behavior, side effects, authentication requirements, or error handling, leaving significant ambiguity.
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 sentence, which is concise but lacks structure. It could benefit from breaking down key points without being verbose, but it is not excessively long.
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 8 parameters, no output schema, and no annotations, the description is very incomplete. It does not describe return values, side effects, or how the parameters interact, leaving large gaps for correct usage.
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 adds no explanation for any of the 8 parameters. The agent cannot infer parameter roles beyond their names and types (e.g., 'key', 'query', 'brands', 'quantity', 'product_id').
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 'Add or update a staple in the reorder catalog' clearly states the action (add/update), the resource (staple), and the context (reorder catalog). Among sibling tools, blinkit_list_staples handles listing, so this tool's purpose is distinct and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when a staple already exists or prerequisites like having an active session. The description only implies the action without contextual advice.
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 provided, so description carries full burden. It discloses return format (product fields, cart_item) implying a read operation. However, it does not mention authentication requirements, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (two sentences), front-loads purpose. Could be more structured but efficient for the information conveyed.
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?
No output schema, but description lists return fields. Missing details on pagination, error handling, and empty results. Adequate for a simple search tool but not fully complete.
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 coverage is 0% (no parameter descriptions). Description does not explain what 'query' or 'page' means. Agent must infer semantics from names alone.
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?
Description clearly states verb 'Search' and resource 'products', distinguishing it from sibling tools like autosuggest. It specifies return format including fields and cart_item. Could be more specific about search type, but adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like blinkit_autosuggest. Does not mention prerequisites or expected use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden but only states the basic function. It does not disclose whether the call is read-only, what data it returns, or any side effects. Critical behavioral context is missing.
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 concise—a single sentence that communicates the core purpose without wasted words. It is appropriately front-loaded, though it could be slightly more structured.
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 the tool has no parameters and no output schema, the description is adequate but lacks detail about the return format (e.g., list of product objects) or whether pagination exists. It does not explain how to interpret the response, which may be needed for an agent acting on the data.
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 schema coverage is trivially 100%. The description adds value by clarifying that the home feed is for the 'saved location', which is a contextual detail not in the schema. Per rules, baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns products on the home feed based on the saved location. While it uses the verb 'surfaced' implicitly, it distinguishes the tool from siblings like blinkit_search or blinkit_recommendations by focusing on the home feed concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., location must be set) or conditions under which the tool should or should not be called.
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 provided, so the description should disclose behavioral traits. It mentions 'reprice' but does not clarify side effects, permissions required, or what happens if the product is not in the cart.
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 a single sentence, front-loaded with the verb 'Remove', and contains no fluff. It is succinct, though it could benefit from slightly more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, the description covers the core action. However, it lacks information about return value, errors (e.g., product not found), or confirmation of removal, which would be helpful for an agent.
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 only parameter, product_id, has no schema description (0% coverage). The description adds minimal meaning ('by id') that is already inferable from the parameter name. More details about expected values (e.g., product ID format) would improve.
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 specific action ('Remove a product from the working cart') and the resource ('product'). It also differentiates from sibling tools like blinkit_add_to_cart and blinkit_clear_cart by specifying removal by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., blinkit_clear_cart for removing all items). The usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits beyond the action, such as whether it is read-only, requires authentication, or has 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 with no wasted words, front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is minimally adequate but could benefit from indicating the read-only nature or typical use case relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the baseline according to instructions is 4. The description adds meaning by specifying what is listed, which is sufficient given the empty 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 clearly states the verb 'List' and the resource 'saved staple catalog and pick preferences', distinguishing it from siblings like blinkit_set_staple. It is specific and not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like blinkit_search or blinkit_home_feed. The description implies usage for viewing saved staples, but lacks explicit context or exclusions.
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?
Without annotations, the description should disclose important behaviors like irreversibility or authentication needs. The minimal description fails to provide any such context.
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 at one sentence, but could be slightly more informative without losing brevity. It's front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks completeness. It does not explain side effects, confirmation, or prerequisites, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description adds no parameter info. Baseline for 0 parameters is 4, and the description is adequate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Empty the working cart' clearly states the verb and resource, distinguishing it from siblings like blinkit_add_to_cart and blinkit_view_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?
No guidance is provided on when to use this tool versus blinkit_remove_from_cart or other alternatives. The description lacks context for appropriate usage.
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 states a login requirement but does not disclose whether the operation is safe (read-only), what data freshness is, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the purpose front-loaded. 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 zero parameters and no output schema, the description provides adequate context: what counts are returned (delivered, live, cancelled) and a prerequisite (login). It could mention that totals are lifetime, but overall complete for a simple read 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?
There are no parameters, so the description does not need to explain them. Schema coverage is 100% (empty). The description adds context about the output (ordered counts by status).
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 it provides lifetime order counts for delivered, live, and cancelled orders. While it distinguishes from many siblings like blinkit_add_to_cart, it could be more specific about how it differs from blinkit_order_history, which might also provide counts.
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 'Requires login,' which is a precondition. No information on when to use this tool vs alternatives like blinkit_order_history or blinkit_login_status.
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 provided, so the description must disclose behavioral traits. It only states the purpose but does not clarify whether the tool is read-only, has side effects, or requires authentication. The agent cannot infer safety or idempotency from this description.
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?
Single sentence that is front-loaded and concise. No wasted words, but could include more detail without being verbose.
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 is simple with 1 parameter and no output schema. The description does not specify the return format (e.g., list of product IDs or objects) or whether it includes pricing/availability. This leaves the agent guessing the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It mentions 'given product id' which adds context but no extra constraints (e.g., format, range). For a single integer parameter, this is acceptable but could be more helpful (e.g., 'must be a valid product ID from blinkit catalog').
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 returns products frequently bought with a given product ID ('people also bought'). The verb 'recommends' and resource 'products' are specific, and the description distinguishes it from sibling tools like search or cart operations.
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?
Implied usage: when a user wants to see 'people also bought' recommendations for a product. However, no explicit guidance on when to use vs. alternatives (e.g., search, home feed), and no exclusions or prerequisites mentioned.
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 exist, so description bears full burden. It mentions the side effect of saving a default location, but lacks details on error behavior, idempotency, or failure modes (e.g., invalid coordinates).
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 a single sentence with minimal words, but it crams multiple sequential actions into one clause, reducing readability. Could benefit from bullet points or separate sentences.
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?
No output schema and no annotations, yet the description covers the core functionality. However, it omits return values, error states, and important behavioral nuances for a setup tool.
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 should elaborate on parameters, but only references 'lat/lon' without specifying format, range, or precision. The schema names are insufficient.
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 outlines a sequence of actions: resolve lat/lon, confirm serviceability, express dark store selection, and save as default. It uses specific verbs and distinguishes from siblings like blinkit_check_serviceability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., blinkit_check_serviceability) or prerequisites (e.g., login status). The description lacks context for appropriate invocation.
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 full burden but only says 'Clear the stored access_token.' It does not disclose whether this operation contacts a server, invalidates the token globally, or if it has side effects on the session state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets straight to the point. It is front-loaded with the key action and is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is minimal. It covers the basic functionality but lacks context about the authentication flow, such as whether it should be called only after successful login or if it is safe to call multiple times.
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 per guidelines, the baseline is 4. The description does not add parameter info, which is acceptable as there are none to document.
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 'Clear' and the resource 'stored access_token', making it immediately obvious that this is a logout action. It distinguishes from sibling authentication tools like blinkit_login_status and blinkit_verify_otp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as whether it should be called after a certain sequence of operations or if there are prerequisites. The description lacks information about typical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes high-level behavior (auto-pick, scorer, swap) but lacks details on the algorithm, failure modes, or side effects. With no annotations, more depth would be beneficial.
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?
Single sentence covering key points. Could be split for readability, but information density is appropriate.
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?
Describes inputs and outputs (chosen product, alternatives, reason) but lacks details on error handling, edge cases, or success criteria. Adequate but not comprehensive for a complex tool without output schema.
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 coverage is 50%, and the description adds minimal meaning beyond the schema. While 'brands' and 'attrs' are hinted, the description does not specify how they are used in scoring or provide examples.
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 the tool searches and auto-picks the best product using a multi-factor scorer, with cheaper-equivalent swap. It returns the chosen product, alternatives, and reason, distinguishing it from sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for auto-picking but does not explicitly state when to use or not use this tool versus alternatives like blinkit_search. No comparison or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions it is a read-like action ('Show'), but it does not clarify if it is non-destructive, what happens if the user is not logged in, or any side effects. With no annotations, the description is insufficient for safety awareness.
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 communicates the core purpose without any unnecessary words. It is well-structured and front-loaded.
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 (no parameters, no output schema) and the presence of related sibling tools, the description is nearly complete. It could mention that the output includes login status and location, but as there is no output schema, this is a minor gap.
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 no parameters, and the schema description coverage is 100% (trivially). The description does not need to add parameter details. Baseline for zero parameters is 4.
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 shows login status and saved location/store. It uses a specific verb ('Show') and resource ('login status' and 'location/store'), and it is distinct from siblings like 'blinkit_logout' which performs an action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'blinkit_logout' or 'blinkit_send_otp'. An agent would need to infer its role as a pre-check 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?
With no annotations provided, the description carries the full burden. It explicitly states the tool does not change the saved location, indicating it is a read-only operation. This discloses its non-destructive behavior clearly, though it omits other details like rate limits or authentication needs.
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, well-structured sentence that front-loads the main action and uses a parenthetical for a crucial clarification. Every word serves a purpose with no redundancy.
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 simplicity of the tool (2 params, no output schema), the description covers the core purpose and side-effect transparency. However, it lacks information about return values (e.g., boolean, message) or error conditions, which an agent would need to interpret the result correctly.
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 add any meaning beyond the parameter names 'lat' and 'lon'. It fails to specify valid ranges, formats, or units, leaving the agent without necessary details for proper invocation.
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 checks if Blinkit delivers to a lat/lon. It also explicitly distinguishes itself from sibling tools like blinkit_set_location by noting it does not change the saved location, which differentiates its purpose well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to check delivery serviceability) and contrasts it with location-changing tools via the parenthetical note. However, it does not explicitly state when not to use it or provide direct alternatives beyond the implicit distinction.
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 for behavioral disclosure. It states the tool is a read operation (list) and requires login, but does not mention potential behaviors such as whether it returns all addresses, pagination, or any side effects. More detail would improve 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 a single concise sentence that front-loads the verb and resource, followed by a key requirement. No unnecessary words.
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 zero parameters, no output schema, and no annotations, the description is minimal but covers purpose and login requirement. However, it could be more complete by clarifying the return format (e.g., list of addresses, possible emptiness). Adequate for low complexity but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%. The description does not need to add parameter meaning. Baseline for 0 parameters is 4, and the description adds no unnecessary info.
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 specifies the verb 'List' and the resource 'saved delivery addresses', including the fields returned (id, label, location). It distinguishes itself from sibling tools like blinkit_add_to_cart, blinkit_search, etc., which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a precondition ('Requires login') but does not provide explicit guidance on when to use this tool versus alternatives, nor does it specify when not to use it. The tool's purpose is clear enough in context of sibling tools, but lacks explicit direction.
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?
Without annotations, the description carries the full burden. It discloses the creation of an order and payment hash, return values (PAS token, orderId, payable amount), and a failure condition (pending payment). However, it omits details about side effects, permissions, idempotency, or rate limits, which are relevant for a payment-related mutation.
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 two sentences, with the core function front-loaded in the first sentence. Every sentence adds value: the first defines the action, the second details outputs and a failure condition. No redundant 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?
Given the tool's simplicity (single parameter, no output schema), the description covers the essential aspects: what it does, what it returns, and a key failure scenario. It is sufficient for an agent to select and invoke the tool correctly, though it could theoretically mention post-usage steps (e.g., using the PAS token).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'cart_id', so the baseline is 3. The tool description adds context that the cart_id is 'from the web cart / checkout', which reinforces the schema but does not significantly augment semantic 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 clearly states the tool's purpose: 'Mint a payment session for a server-synced cart'. It uses a specific verb ('mint') and resource ('payment session'), and differentiates from siblings by focusing on payment preparation, whereas other tools handle cart manipulation, search, or authentication.
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 provides context by specifying 'for a server-synced cart' and noting that it fails if a pending payment exists. However, it does not explicitly state when to use this tool versus alternatives like blinkit_checkout or blinkit_pay_upi, nor does it offer exclusions or comparative guidance.
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 behavioral traits. It only says 'Show', implying read-only, but does not explicitly state it is non-destructive, idempotent, or requires authentication. No side-effects or permissions are addressed.
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 front-loads the action ('Show the working cart, repriced') and lists key output elements. 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?
For a simple view-only tool with no parameters, the description provides essential information about the tool's purpose and output. It could mention that the tool is safe and read-only, but overall 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?
The input schema has no parameters, so description coverage is 100%. The description adds meaning by listing what is shown (items, payable amount, delivery, MROV), which is useful for understanding the output without an output 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 tool's function: showing the working cart with updated pricing, including items, payable amount, delivery, and MROV. It distinguishes from sibling tools like blinkit_add_to_cart and blinkit_clear_cart which modify 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 description implies use for viewing the cart but does not explicitly state when to use it vs alternatives like blinkit_checkout or blinkit_prepare_order. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'reprice' as a side effect, but does not reveal whether the action is reversible, what permissions are needed, or any error conditions. The description is too minimal to fully inform the agent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of exactly two short sentences. Every word serves a purpose, with no redundancy or filler. It is front-loaded with the primary action and immediately provides input guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple add-to-cart tool with one parameter, the description covers the essential action and input source. However, it omits details on what the tool returns (no output schema exists) and the resulting cart state (e.g., whether the cart is now ready for checkout). This leaves some gaps for the agent to infer.
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% (the 'items' parameter has a description). Beyond that, the description adds value by specifying that inputs should come from blinkit_search/blinkit_pick_best, providing context not present in the schema alone. This helps the agent understand the expected data origin.
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 that the tool adds line items to the working cart and reprices. It uses a specific verb ('Add') and resource ('line items to the working cart'), and implies the tool is for adding multiple items. This distinguishes it from sibling tools like blinkit_remove_from_cart and blinkit_clear_cart.
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 tells users to pass product objects returned by blinkit_search or blinkit_pick_best, establishing a clear prerequisite. However, it does not explicitly state when not to use this tool or compare it to other cart-related tools like blinkit_checkout, leaving some room for ambiguity.
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 explaining behavior. It discloses that the tool creates a real server cart, binds address, and validates. However, it does not mention side effects (e.g., clearing previous cart), authorization needs, or rate limits, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, consisting of two sentences. The first sentence front-loads the core action, and the second sentence provides essential integration context. 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?
Given the tool's moderate complexity (nested array, two required params, no output schema), the description effectively covers purpose, action, and downstream usage. Minor gaps exist, such as missing details on item object fields or potential errors, but it remains largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implicitly references 'items' and 'address' but does not describe parameter structure or constraints. Schema coverage is 0%, so the description adds some context beyond property names but lacks formal semantics, such as field explanations or required nested fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating a server cart from items, binding delivery address, and validating. It also specifies the return value (cart_id) and its use in subsequent tools, distinguishing it from siblings.
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 indicates that this tool is a prerequisite for blinkit_prepare_order and blinkit_pay_upi by stating the cart_id returned should be passed to them. It provides clear context for when to use, though it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Adds login requirement as behavioral context, but does not disclose if tool is read-only, whether it modifies state, or any side effects. Adequate but not thorough.
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?
Single sentence with no wasted words. Front-loads return fields and ends with prerequisite. Highly efficient.
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 parameterless tool with no output schema, description covers returned fields adequately. Lacks details on recency limits or pagination, but sufficient given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100% trivially). Baseline of 4 for zero parameters is appropriate; description adds no extra param info but doesn't need to.
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 it returns recent orders with specific details (totals, status, item names, reorder product ids) and requires login. This distinguishes it from siblings like blinkit_order_count (just count) and blinkit_payment_status (payment only).
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?
Description implies use for retrieving detailed order history but does not explicitly state when to use over alternatives like blinkit_order_count or blinkit_quick_reorder. No exclusions or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses return values (pending/success/failed) and says 'without re-initiating it', but does not mention side effects, permissions, or rate limits. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and constraint, second states return values. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check with one optional parameter and no output schema, the description covers purpose, parameter behavior, and return values. Lacks error handling details but is sufficient.
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 schema's description of 'cart_id' already states 'optional; defaults to the most recent payment'. The tool description repeats this, adding no new information 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 specific verb 'Check' and resource 'in-flight UPI payment'. It clearly distinguishes from sibling blinkit_pay_upi which initiates payments.
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?
Describes when to use (check status, not initiate) and implies not to re-initiate. Could mention explicit alternative (blinkit_pay_upi) but clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that with no keys, it adds all auto-eligible staples 'silently', which gives a behavioral trait (silent addition). It also mentions the return value (repriced cart and choices). However, it does not clarify whether the cart is cleared before adding, or if it appends to existing items, leaving some ambiguity about cart mutation.
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, each sentence providing essential information: first sentence states the action and modes, second sentence states the return. No fluff, front-loaded with the main 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?
For a simple tool with one optional parameter and no output schema, the description covers both modes (with/without keys) and the return value (repriced cart and choices). It lacks mention of error conditions or prerequisites (e.g., having saved staples), but overall is sufficiently complete given the low 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 100% with one parameter 'keys' described as 'staple keys to reorder; omit for all auto staples'. The description adds that resolving the keys is done for given keys, which matches the schema. With high schema coverage, the description adds minimal extra meaning beyond confirming behavior.
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 rebuilds a basket from saved staples, using specific verb 'rebuild' and resource 'basket from saved staples'. It distinguishes from siblings like blinkit_add_to_cart (individual items) and blinkit_list_staples (listing) by specifying it works with saved staples. The behavior with and without keys is explicitly described.
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 explains when to use keys (to resolve specific staples) and when to omit (for all auto-eligible staples). However, it does not explicitly state when not to use this tool vs alternatives like blinkit_add_to_cart, though it is implied by the concept of 'saved staples'.
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, description carries full burden. It mentions headless execution but does not disclose side effects (e.g., SMS sending, rate limits) or whether login state changes. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, essential information front-loaded.
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 1-parameter tool with no output schema, description is adequate. Mentions step 1 of login, providing sequencing context. Could briefly hint at next step (verify OTP).
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 already covers the phone parameter with format example. Description does not add new meaning beyond 'phone number'. Schema coverage is 100%, so baseline score 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?
Description clearly states the tool sends a login OTP to a phone number, specifying it is headless and step 1 of login. This distinguishes it from sibling tools like 'blinkit_verify_otp'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly identifies it as step 1 of login, implying usage before verification tools. However, does not mention scenarios where it should not be used (e.g., if already logged in).
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 that a wrong code returns ok:false despite Blinkit success and that access_token is persisted. Adequate for a simple verification 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?
Two sentences, front-loaded with action, efficient. The behavioral note is essential and included without extra 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 no output schema and only 2 simple parameters, description covers core action, step context, and a critical behavioral quirk. Slightly lacking in parameter detail but overall sufficient.
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 coverage is 50% (only 'code' described). Description does not add any parameter details beyond the schema; phone parameter remains undescribed.
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 verifies OTP and persists access_token, and identifies itself as Step 2 of login, distinguishing it from sibling auth tools like blinkit_send_otp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly labeled as 'Step 2 of login' implying sequential use after sending OTP. Includes a note about behavior on wrong code, but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that 'qr' returns a UPI link, 'collect' pushes a collect request, and polling is needed. It does not cover auth, rate limits, or error behavior, but for a payment initiation, the core behavior is transparent enough.
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: first states the overall action, second details methods and polling. It is front-loaded, efficient, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the initiation and polling but lacks details on return values (e.g., what 'collect' returns), failure modes, and security aspects. It is adequate but not fully complete for a 4-parameter 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 50% of parameters with descriptions. The description adds meaning by explaining method values and the polling process (for 'wait'), compensating for low coverage. However, 'cart_id' receives no additional context 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 action is to initiate UPI payment on a prepared order using Zomato zpaykit. It distinguishes two methods ('qr' and 'collect') and mentions polling, making it distinct from sibling tools like blinkit_payment_status.
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 is used after a cart is prepared (via blinkit_prepare_order) and suggests polling status afterward. It explains when to use 'qr' vs 'collect' but does not explicitly exclude cases or compare to alternatives like blinkit_payment_status.
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:

[![blinkit-mcp MCP server](https://glama.ai/mcp/servers/yniks/blinkit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yniks/blinkit-mcp)

Score Badge

Copy to your README.md:

[![blinkit-mcp MCP server](https://glama.ai/mcp/servers/yniks/blinkit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/yniks/blinkit-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/yniks/blinkit-mcp'

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