compu-ai-mcp

by Javiervalladares1

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: searching, retrieving details, checking availability, getting price, comparing, recommending, listing plans, calculating installments, reserving, releasing, creating order, checking order status, getting policies, and creating quotes. No overlapping functionality is evident.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_products, get_product_details, reserve_item, create_order). The naming style is uniform and predictable.
Tool Count5/5
With 14 tools, the set is well-scoped for a store operation domain. It covers a broad range of customer and sales workflows without being excessive or sparse.
Completeness5/5
The tool surface covers the full lifecycle from product discovery (search, details, compare) to transactional actions (reserve, order, quote) and support (policies, installment plans). No critical gaps are apparent.
Average 4.3/5 across 14 of 14 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes 'This writes to the database', which is important because readOnlyHint is false. It also discloses the return value (quote code). It does not describe idempotency, but the annotations already indicate idempotentHint is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, covering the action, optional parameter, return value, and side effect in three short sentences with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description mentions the returned quote code and states the database write. It is sufficient for basic invocation, though it does not cover prerequisites, error behavior, or when a quote should be created instead of an order.
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 describes customer, plan_id, and quantity. The description adds little beyond 'optionally under an instalment plan', which mirrors the schema. The sku parameter has no description, though its name is self-explanatory.
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 action ('Create a formal quote'), the target (customer/plan), and the return value (quote code). It also explicitly says it writes to the database, making the tool's purpose unambiguous and distinct from order creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives like create_order, or when to first consult list_installment_plans. The description relies on the tool name and sibling context rather than stating usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that this writes to the database (non-read-only) and that it fails on insufficient stock, aligning with the annotations. It also hints at idempotency through the idempotency_key, but does not fully detail all side effects or error handling.
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 brief and to the point, consisting of three short sentences. No extraneous information or repetition is present, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and failure condition, but it does not mention expected return values or output format, nor does it explain the reservation lifecycle or how it relates to release_reservation. Some context is missing for full autonomous use.
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 covers 60% of parameters with descriptions, but sku and customer lack any description, and quantity/ttl_minutes only have default values. The tool description does not clarify the meaning or format of these parameters, leaving ambiguity for the agent.
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 (hold/reserve), the resource (SKU units), the condition (fails if insufficient stock), and a note to confirm with the salesperson. It is specific and unambiguous about the tool's primary 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 description provides a usage hint ('confirm with the salesperson first') and implies a precondition (check stock), but it does not explicitly compare with alternative tools or specify when not to use this tool. The guidance is present but not fully 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?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description's 'Look up' is consistent. However, it adds no extra behavioral context such as error conditions or rate limits beyond what annotations cover.
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, clear sentence with no superfluous words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status lookup, the description fully specifies the input (order code) and output (current status), providing everything an agent needs to invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full documentation for the single parameter 'order_code' with an example, and the tool description adds no further semantic detail about the parameter.
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 ('Look up'), the resource ('order'), and the return value ('current status'), making the tool's primary purpose unambiguous and distinct 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly indicate when to prefer this tool over alternatives like search_products or get_product_details, though the specificity of 'order code' provides implicit 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?
Annotations already mark the tool as read-only (readOnlyHint: true), so the description does not need to repeat that. However, it adds no further behavioral details (e.g., output format, potential errors, or performance considerations). The description covers purpose more than transparency, so a score of 3 is appropriate.
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, clear sentence that conveys all essential information without redundancy. It is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description provides sufficient context: what the tool does, the input (SKUs), and the scope (two to four). No additional information is needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'skus' parameter, but the tool description explains that it compares two to four SKUs, indicating that 'skus' are the identifiers of the items to compare. This adds meaning to an otherwise bare parameter, meeting the compensation requirement for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: comparing two to four SKUs side by side, listing specific attributes (price, key specifications, warranty, availability). It also implicitly distinguishes itself from sibling tools like search_products or get_product_details by focusing on multi-item comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it over alternatives or provide conditions for selection. While the name and sibling context make usage obvious, the lack of explicit guidance prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the lack of side effects, and the description adds the expected output composition. It does not describe error behavior or missing-price handling, but for a read-only lookup this is not a critical omission.
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 and front-loads the core purpose. Every phrase adds useful information, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description provides enough context: what is returned and that this is the canonical source. The lack of an output schema is partially mitigated by naming the returned price components, though error cases are not addressed.
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 defines sku as a required string, and the description repeats the term SKU without adding format details or examples. The parameter is self-explanatory to most users, but the description adds minimal semantic value 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 tool returns the current price of a SKU and enumerates the specific price components (list price, active promotion, final cash price, card price). It also distinguishes this tool as the authoritative price source, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This is the only valid source of prices,' providing strong guidance to prefer this tool for price lookups. It could more explicitly contrast with related tools like get_product_details or compare_products, but the guidance is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context by specifying it returns real stock and prices with active promotions applied. This goes beyond the annotation and helps the agent understand the output semantics without needing an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main verb and resource, then returning output and usage. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, output, and usage guidance. It does not explain how multiple filters combine or mention the limit parameter, but the schema documents limit defaults and other details. For a read-only search tool with no output schema, this is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with brand and category lacking descriptions. The description adds some meaning by clarifying that filters are combinable ('by free text, category, brand and/or maximum budget') and that max_price represents a budget, but it does not fully compensate for the missing brand/category descriptions or explain how filters interact (e.g., AND vs OR). This is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the store catalogue using free text, category, brand, and/or budget, and explicitly lists what it returns (SKU, price with promotions, real stock). This differentiates it from sibling tools like get_product_details or check_availability by establishing it as the general catalogue search entry point.
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 gives clear usage context: 'Use this before answering anything about what the store sells.' This directs the agent to use it as a first step. However, it does not explicitly mention when not to use it or name alternatives, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states it writes to the database and discounts units from stock, aligning with the destructive annotation and making side effects clear. No hidden surprises.
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 deliver the essential information with no redundant wording. The structure is clean and easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and side effects, and the caution about salesperson confirmation adds important context. It does not mention return values or error scenarios, but these are not critical for a simple write operation among siblings.
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 description does not explain the parameters. Only plan_id has a schema description, and reservation_code and payment_method are left undocumented in both schema and description. This would force the agent to infer meanings from names alone.
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: turning an active reservation into a confirmed order and reducing stock. It uses a specific verb and defines the resource and outcome unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a direct usage instruction to confirm with the salesperson before calling, and implies this is a state-changing operation. This is helpful guidance, though it could be more explicit about when not to use it (e.g., if a reservation is expired).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description and readOnlyHint align: the tool is a read-only lookup with no side effects. It does not detail error cases or response format, but the read-only nature is clear and no contradictions exist.
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, compact sentence that efficiently communicates purpose and scope without extraneous detail. The list of included attributes is well organized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough detail for an agent to know what information will be returned, even without an output schema. It lacks explicit mention of return format or error behavior, but for a simple SKU lookup the context is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single sku parameter is fully explained with a concrete example and is consistent with the description's 'by SKU' phrasing. The schema covers 100% of the parameter, so no semantic gaps remain.
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 retrieves full product details by SKU, enumerating specifications, price, promotion, warranty, and stock by condition and location. This distinguishes it from narrower siblings like get_current_price or check_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when full product detail by SKU is needed), but it does not explicitly contrast it with alternatives such as search_products, get_current_price, or compare_products. There is no direct 'use this instead of X' guidance, though the scope is inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers side-effect transparency. The description adds context about the calculation inputs (promotion, surcharge, fee, interest) but does not explicitly state that no data is modified; however, this is adequately covered by the annotation.
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 three concise sentences with no redundancy. It front-loads the core purpose, then details the included factors, and ends with a clear directive. Every sentence adds value.
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 calculation tool with no output schema, the description covers the essential behavior, the mandatory usage rule, and the components of the calculation. It does not mention potential error conditions, but given the readOnly annotation and low complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives some context for sku and plan_id (via 'for a SKU under one instalment plan'), but it does not explain the sku format or the quantity parameter beyond the schema's minimal 'Default 1.' With schema coverage at 67%, the description adds limited value for parameter understanding.
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 'calculate' and the specific output ('exact monthly payment') for a given SKU and installment plan. It also sets a strong expectation with 'Never quote instalments without calling this,' making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs when to use the tool ('Never quote instalments without calling this'), which serves as a definitive usage rule. It also lists what the calculation includes (promotion, surcharge, fee, interest), clarifying the scope of the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only annotation is consistent with the check action, and the description adds the calculation formula, though it does not discuss auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences convey purpose, formula, and usage without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description is complete enough; it clarifies the meaning of availability and when to call it, though it leaves the exact output format implicit.
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 identifies the parameter as a SKU but does not specify format, validation, or examples, so it adds only basic meaning 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 tool checks available units for a SKU, with a specific formula (on hand minus reserved), distinguishing it from product detail or price tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage directive: use before promising anything to a customer, making the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by implying the tool checks availability ('propose available products'). This adds a behavioral detail—filtering for availability—that is not explicitly stated in the annotations. It does not contradict the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured—two sentences that state the action and the usage condition. It is front-loaded with the purpose and contains no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficiently complete for a simple read-only tool. It indicates the output (proposed products) without needing a formal output schema. It does not mention error handling or edge cases, but given the straightforward nature, this is acceptable. A minor gap is not specifying the format of the returned products, but this is not critical.
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 provides additional context for the 'sku' parameter by framing it as 'the customer wanted.' However, it does not clarify the meaning or purpose of 'limit' or 'max_price' beyond what the schema already states. Since the schema already covers all parameters, the description adds minimal extra value for these 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 function: proposing available products from the same category and similar price range given a SKU. It uses specific action verbs ('propose') and identifies the resource (SKU) and the output (products). This distinguishes it from sibling tools like search_products or get_product_details, which do not focus on alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a usage condition: 'Use this when the requested product is out of stock or over budget.' This gives clear guidance on when to invoke this tool versus alternatives, leaving no ambiguity about the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key side effect: writing to the database and returning units to available stock. It does not describe error cases or repeated-call behavior, but the idempotentHint annotation covers idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundant wording; the purpose and side effect are front-loaded before the database note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter write action, the description covers purpose, side effect, and parameter adequately. It omits output or error behavior, but no output schema is provided and the operation is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The reservation_code parameter is required and clearly described as the code returned by reserve_item, with a concrete format example.
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 ('Release an active reservation'), the object ('reservation'), and the effect ('return the units to available stock'), leaving no ambiguity about 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates this is a state-changing database write and implies it should be used for reservations that should no longer be active. It does not explicitly contrast with sibling tools like reserve_item or create_order, so usage guidance is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates non-destructive behavior, and the description aligns by using 'List'. The phrase 'currently offered' adds a subtle behavioral nuance (data may change over time), enhancing transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It states the purpose and the optional filter efficiently, adhering to good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple list operation and no output schema, the description provides sufficient context: what it does, what it lists, and the optional filter. It does not need to explain return format or side effects, as those are either obvious or covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'amount' is described with both its meaning ('Amount to finance') and currency ('quetzales'). This fully covers the parameter's semantic intent, complementing the type information in 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 ('List') and the resource ('installment plans'), and specifies an optional filter by amount. This is unambiguous and distinguishes it from sibling tools that perform different actions like search or calculate.
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 mentions the optional filter for amount, giving a clear usage condition. It does not explicitly compare to alternatives, but the purpose is distinct enough that an agent can infer when to use it. Slight deduction for lacking an explicit 'when not to use'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint is true, indicating no side effects. The description itself implies a safe read operation by listing information retrieval. No contradictions exist, and the absence of side effects is evident.
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 exceptionally concise—two short sentences that list the policies and provide usage guidance. Every word adds value, with no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only policy retrieval tool, the description is complete. It covers what the tool returns (policies) and when to use it. The optional key behavior is implied and covered by the schema, so no essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single optional 'key' parameter with an enum and description. The tool description reinforces the parameter by listing the same policy types, aiding understanding, though it adds no new detail 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 tool's purpose: providing current store policies for business hours, location, warranty, returns, and shipping. It also explicitly instructs to use this instead of answering from memory, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides direct usage guidance by saying 'Use this instead of answering from memory,' which tells the agent when to invoke this tool versus relying on internal knowledge. The context of policy retrieval is clear.
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

compu-ai-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![compu-ai-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Javiervalladares1/compu-ai-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Javiervalladares1/compu-ai-mcp)

Score Badge

Copy to your README.md:

[![compu-ai-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Javiervalladares1/compu-ai-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Javiervalladares1/compu-ai-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/Javiervalladares1/compu-ai-mcp'

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