pelando-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PELANDO_LOG_LEVEL | No | structlog level. | INFO |
| PELANDO_CACHE_PATH | No | Path to sqlite cache. Defaults to /data/cache.sqlite in Docker, data/cache.sqlite locally. | /data/cache.sqlite |
| PELANDO_USER_AGENT | No | Sent on every request. Identifies the client truthfully. | pelando-mcp/0.1 (+repo url) |
| PELANDO_RATE_LIMIT_RPS | No | Max requests/sec. | 1.0 |
| PELANDO_RATE_LIMIT_BURST | No | Token-bucket burst. | 3 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_dealsA | Search deals that Pelando users have posted. Returns community postings, NOT a catalogue: one merchant per posting, free-text titles, and only products someone chose to post. There is no product database behind this — even mainstream terms can legitimately return nothing. Pelando's search is token-based and loose ("iphone 16 pro" matches "iPhone 14 Pro ... 16"),
so each result carries a Only |
| browse_feedB | Browse Pelando's own feeds, optionally scoped to one community.
|
| get_dealB | Fetch one deal by UUID or by slug. A slug works directly, so a URL the user pasted ( |
| get_deal_commentsB | Read a deal's comment thread — where the crowd corrects a bad posting. The thread is the only place a fake discount gets explained; there is no report or flag
field in Pelando's data. Note the upstream endpoint has no pagination and returns the whole
tree at once, so |
| assess_deal_qualityA | Judge whether the community believes a deal is genuine. This is what Pelando has that a price comparator does not. It reads the crowd's vote
( Returns a verdict WITH its evidence attached, never a bare score — present the reasoning to the user rather than the label alone. It judges community sentiment, not merchant truth: it cannot verify that the price is real or still available. |
| search_storesA | Look up a merchant: its live activity counts and its top coupons. Matching is loose and substring-based upstream — "amazon" also returns "Amaro" — so results are ranked here by how closely the name matches, but the caller should still check the name before acting on the first row.
|
| get_store_couponsA | Fetch a store's coupon codes.
Coupons expire silently. Every code is reported with the date it was posted so its age is visible; none of them is guaranteed to still work. |
| list_communitiesA | List Pelando's 11 communities — the site's only browse taxonomy. There is no category system beside this: deals carry a bare numeric |
| pingA | Liveness check. Returns server name, version, and runtime config. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct action+resource: search_deals vs browse_feed are separated by query-based vs community-feed retrieval, search_stores vs get_store_coupons split merchant lookup from coupon codes, and get_deal/get_deal_comments/assess_deal_quality are clearly layered. Descriptions explicitly state boundaries and upstream limitations, leaving little room for misselection.
Uniform snake_case verb_noun pattern throughout (search_deals, browse_feed, get_deal, get_deal_comments, assess_deal_quality, search_stores, get_store_coupons, list_communities, ping). Verbs are used consistently and predictably for their intent.
Nine tools is well within the ideal 3-15 range and each one maps to a distinct capability (search, browse, fetch, comments, quality, stores, coupons, taxonomy, liveness). No filler or redundant tools.
The read-only deal-consumption surface is thorough: discovery (search/browse), retrieval (deal/comments), trust assessment, stores, coupons, and taxonomy are all covered. Minor gaps exist—no direct store-deals listing (only a documented workaround) and no pagination for comments beyond local truncation—but agents can work around these.