SiteCheck Shop & Social

Cost Plus Drugs mail-order cash prices from its official

ecommerce_costplusdrugs

Read-only

Cost Plus Drugs mail-order cash prices from its official pricing API: search by drug name (optionally strength) or NDC; returns medication and brand name, generic/brand, form, strength, treatment categories, pack size, RxNorm ID, in-stock flag, price per unit (USD, incl. markup), cash dispensing fee, 30/60/90-count pack prices with and without fee, total with shipping, and product URL. Only drugs sold on the CPD mail-order channel. Related tools on this server, for a different need: ecommerce_rappi when you need Rappi restaurant menu and prices: for a Rappi store ID; ecommerce_singlecare when you need SingleCare prescription coupon prices for a drug: price. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ecommerce_costplusdrugs"
  }
}

Input Schema

Name	Required	Description
`ndc`	No	National Drug Code, with or without dashes, e.g. 67877-0511-10 (matches generic equivalents)
`term`	No	Drug or brand name, partial match, e.g. atorvastatin or Lipitor (term or ndc required)
`limit`	No	Max results 1 to 100 (default 25)
`strength`	No	Strength filter with term, e.g. 20mg

Output Schema

Name	Required	Description	Default
`count`	No
`drugs`	No
`query`	No
`total`	No
`source`	No
`currency`	No
`checkedAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint; the description goes well past them by disclosing the billing model ('$0.002 in USDC per successful call, paid with x402'), the payment rails accepted, and that 'failed calls are not charged'. It also limits the catalog to the mail-order channel, which explains empty results for retail-only drugs.

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?

Purpose and channel scope are front-loaded, but the middle of the description is a long enumeration of return fields (RxNorm ID, pack sizes, 30/60/90-count prices, shipping, URL) that duplicates the existing output schema. The pricing and sibling-routing sentences earn their place; the field dump does not.

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?

With an output schema present, the agent does not need the description to explain return values, and the description still covers the things structured fields cannot: catalog scope, per-call cost and payment mechanics, and failure billing. Nothing required to invoke or interpret a call correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the four parameters are already documented with examples and defaults; the description matches but does not extend them. It conveys the combination rule ('optionally strength', 'term or ndc required') and that NDC matching covers generic equivalents, but adds no format or constraint detail beyond the schema text.

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 names a specific verb and resource ('search' Cost Plus Drugs mail-order cash prices) and pins down the input keys (drug name, optional strength, or NDC) plus the channel scope ('Only drugs sold on the CPD mail-order channel'). It also explicitly names two sibling tools with the conditions that select them, so an agent can separate it from ecommerce_singlecare and ecommerce_rappi without inspecting schemas.

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?

Usage is spelled out on both sides: it states the lookup axis ('search by drug name (optionally strength) or NDC') and routes the agent elsewhere for adjacent needs ('ecommerce_singlecare when you need SingleCare prescription coupon prices for a drug'). A negative scope boundary is also supplied ('Only drugs sold on the CPD mail-order channel'), which tells the agent when this tool will return nothing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SiteCheck Shop & Social tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?