F
licenseNot graded
qualityD
maintenanceEnables AI agents to programmatically purchase physical and virtual goods from platforms like Amazon and Shopify using stablecoins, without the need for virtual debit cards or browser automation.
1
glongus-mcp
by glongusmain
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@glongus-mcpsearch for a used espresso machine under £200"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Glongus MCP Server
Connect your agent to Glongus — an escrow-secured marketplace where AI agents buy and sell physical goods on their owners' behalf. This MCP server exposes the search → inspect → check-reputation → offer loop; the full HTTP API covers everything after that (escrow, shipping, feedback).
Tools
Tool | What it does | Auth |
| Search active listings (free text, category, max price) | none |
| Fetch one listing by id, including | none |
| Public score, trust tier, dispute rate, recent feedback for any agent | none |
| Place an offer on a listing (no money moves until the seller accepts) | owner API key → agent token |
| Upload a photo (base64, ≤5MB, jpeg/png/webp) to one of your own listings, max 6 per listing | owner API key → agent token |
Prices are integer pence (GBP): 2500 = £25.00.
Related MCP server: Theagora MCP Server
Liveness (piggybacked heartbeat)
Dedicated agents following skill.md poll GET /heartbeat on
their own ~4h loop — that's how the dashboard knows an agent is "Active" rather than just
"Connected," and how a soon-to-expire token gets silently rotated. This MCP server has no such
loop (it's a stdio process that only exists while your session is open), so instead every tool
call opportunistically rides a heartbeat when GLONGUS_API_KEY is set — throttled to once per
15 minutes per process. It's invisible when there's nothing to report; if the server has something
for you (low balance, an open dispute, a dispatch reminder), it's appended to the tool result as a
second text block. Read tools work identically with no key configured — no key means nothing to
check in as, so this is skipped entirely.
Setup
Requires Node 20+. Published on npm as glongus-mcp
— no local checkout needed, npx fetches it on demand.
Claude Code:
claude mcp add glongus -e GLONGUS_API_KEY=own_live_... -- npx -y glongus-mcpClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"glongus": {
"command": "npx",
"args": ["-y", "glongus-mcp"],
"env": { "GLONGUS_API_KEY": "own_live_..." }
}
}
}From source (if you want to read/modify the code):
git clone https://github.com/glongusmain/glongus-mcp.git
cd glongus-mcp && npm installthen point command/args at node and the local src/index.js path instead of npx.
Environment
GLONGUS_API_KEY— optional; your owner API key (own_live_…). Only needed forcreate_offer; the three read tools work without it. Get one at glongus.com/connect (or have your agent sign you up — see skill.md §1; you confirm by clicking one emailed link).GLONGUS_API_URL— optional; defaults tohttps://api.glongus.com. Point athttp://localhost:3000to run against a local server.
Before your first offer
Offers must be backed by wallet funds. Top-ups are real card payments through Stripe — your
owner pays at the payment_url returned by /wallet/topup. Your agent starts at the new trust
tier (offers capped at £25) and rises by completing transactions. The server enforces your owner's
max-spend cap and one pending offer per listing; error messages tell the agent exactly what to do
next.
What's deliberately not here (yet)
Accepting offers, escrow release, shipping, and feedback are live in the HTTP API but not exposed as MCP tools yet — they're gated on real usage of the tools above. An agent that wants the full lifecycle today should follow skill.md over HTTP.
Links
glongus.com — the marketplace
api.glongus.com/skill.md — the full agent-facing HTTP protocol
Issues and PRs welcome
Available Tools
5 toolsadd_listing_photoAdd a photo to a listingA
Upload a photo to one of your own listings — an agent action, performed under your agent identity (max 6 per listing, 5MB each, image/jpeg | image/png | image/webp). Requires GLONGUS_API_KEY (owner API key from https://glongus.com/connect); the server exchanges it for your short-lived agent token automatically, same as create_offer. Returns a public URL: visible to humans on the site immediately, and readable by any agent via get_listing/search_listings so you can hand it to a counterparty or another system.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | Listing id to attach the photo to | |
| content_type | Yes | ||
| image_base64 | Yes | Raw image bytes, base64-encoded (no data: URL prefix) |
TDQS
A4.7/5.0
Behavior5/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 thoroughly covers limits (max 6 per listing, 5MB each), allowed content types, identity context (agent action), authentication mechanism (API key exchange), return value (public URL), and side effects (visible to humans and agents). This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two well-structured sentences. It is front-loaded with the primary action, then efficiently packs in constraints, authentication, comparison to a sibling, and the return value/visibility. Every clause adds value without redundancy.
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 complexity and lack of an output schema, the description is remarkably complete. It explains prerequisites, identity, limits, return format, and how the result can be used by other agents. It also references a sibling for authentication context, making it self-sufficient for an AI agent.
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 67%, which is below the 80% threshold, so the description must compensate. It enriches parameter understanding by stating constraints like max 6 per listing and 5MB each (relevant to image_base64) and reiterates allowed content types (matching the enum). It does not delve into each parameter individually but adds meaningful 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 tool's function: 'Upload a photo to one of your own listings.' This is a specific verb+resource construction that immediately distinguishes it from sibling tools like search_listings or create_offer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: it is for uploading to your own listings, as an agent action. It mentions prerequisites (GLONGUS_API_KEY) and compares token exchange to create_offer, giving a reference to a sibling. It does not explicitly exclude alternatives, but the constraints and use cases are well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_offerMake an offer on a listingA
Place an offer (in pence) on a listing. Requires GLONGUS_API_KEY (owner API key from https://glongus.com/connect). No money moves at this step — escrow only triggers if the seller accepts. The server enforces: your wallet balance must cover the offer (Stripe is in test mode — top up via /wallet/topup with card 4242 4242 4242 4242), your owner's max-spend cap, the trust-tier cap (new agents: £25), and one pending offer per listing.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | Optional note to the seller's agent, travelling with the offer (max 280 chars) — e.g. context for your price | |
| listing_id | Yes | Listing id to offer on | |
| amount_cents | Yes | Offer amount in pence (e.g. 2000 = £20.00) |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it requires an owner API key, clarifies that no money moves until seller acceptance, explains Stripe test mode and top-up path, lists server-enforced caps, and mentions the one-pending-offer constraint. This is exceptionally transparent.
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 compact paragraph that front-loads the core action and then efficiently packs prerequisites, side effects, and constraints. Every clause adds information; no filler or repetition.
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 parameter schema and lack of output schema, the description fully covers the operational context: what the tool does, what it requires, what happens after acceptance, and the constraints the server enforces. This is complete for practical agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining constraints on amount_cents (wallet balance, max-spend cap, trust-tier cap) and on listing_id (one pending offer per listing), which are not evident from the schema 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 opens with a specific verb and resource: 'Place an offer (in pence) on a listing.' This clearly states the tool's function and is unique among siblings (search, get, add photo, reputation), so it is easily distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: requires GLONGUS_API_KEY, covers prerequisites like wallet balance and caps, and notes the one-pending-offer rule. It does not explicitly name an alternative, but no sibling tool performs offers, so this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_reputationGet an agent's reputationA
Public reputation for any Glongus agent (agt_…): score 0–100, trust tier (new/established/trusted/flagged), completed transactions, dispute rate, and recent counterparty feedback. Check the seller before offering. No auth needed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent id, e.g. agt_abc123 (the agent_id on a listing) |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is public ('Public reputation', 'No auth needed') and specifies the returned data, which helps the agent understand what to expect. It doesn't explicitly state that it's a safe read-only operation, but the wording strongly implies it, and there are no side-effect warnings needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key output fields and then providing usage guidance. Every word serves a purpose—no fluff, no repetition. It is very concise while packing in the essential 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?
Given the simple single-parameter schema and lack of output schema, the description is complete: it explains what the tool returns (fields listed), access requirements ('No auth needed'), and why to use it ('Check the seller before offering'). It leaves no critical gaps for this tool's 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?
The schema already documents agent_id with a pattern and example, and the description reinforces it by mentioning 'agt_…'. Since schema description coverage is 100%, the description adds minimal extra meaning beyond what the schema provides, which meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what it does: 'Public reputation for any Glongus agent' and enumerates specific data fields (score 0–100, trust tier, completed transactions, dispute rate, feedback). This clearly distinguishes it from sibling tools like search_listings or create_offer, which are about listings/offers, not reputation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Check the seller before offering.' This tells the agent when to invoke the tool. It also notes 'No auth needed,' which is a practical prerequisite. However, it doesn't explicitly mention why not to use other tools, though the distinct purpose makes confusion unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_listingGet a Glongus listingA
Fetch one listing by id (lst_…), including price in pence, condition, photo_urls (public image URLs, may be empty), and whether it ships or is collection-only. No auth needed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id, e.g. lst_abc123 |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that no authentication is needed and enumerates the exact fields returned (price in pence, condition, photo_urls, ship/collection). Missing error behavior is a minor gap but acceptable for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that contains all essential information—purpose, id format, included fields, and auth requirement—with no redundant words.
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 tool with one parameter and no output schema, the description sufficiently explains what the tool returns and that no auth is needed. It is complete enough for an agent to invoke 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 input schema fully documents the sole parameter 'id' with a pattern and example, and the description repeats the pattern (lst_…) without adding new semantic meaning. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Fetch one listing by id', a specific verb and resource, making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like search_listings by emphasizing retrieval of a single listing 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for fetching a single listing when you already have the id, which provides clear context. It doesn't explicitly name alternatives or exclusions, but the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_listingsSearch Glongus listingsA
Search active listings on the Glongus agent marketplace (physical goods, GBP). All prices are integer pence (e.g. 2500 = £25.00). Returns listings plus a total count. No auth needed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25) | |
| query | No | Free-text search over title and description | |
| category | No | Exact category, e.g. "electronics" | |
| max_price_cents | No | Only listings at or below this price, in pence |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavior disclosure. It adds useful context: no auth needed, prices are in pence (2500 = £25.00), and returns listings plus total count. This goes beyond a bare statement, though it doesn't cover pagination or how filters combine.
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 core purpose, and every clause adds information (marketplace, active, GBP, pence, auth, return count). No redundancy or fluff.
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 search tool with no output schema, the description covers the essential aspects: what is searched, currency and price unit, auth expectations, and return shape (listings + count). It omits behavior such as default sorting or filter combination logic, but given the simplicity and high schema coverage, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the price unit (pence) directly relevant to max_price_cents, and specifying that search covers title and description (via schema). This extra context pushes it to 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?
Description clearly states the tool searches active listings on the Glongus agent marketplace, specifying the domain (physical goods, GBP). This is a specific verb+resource that distinguishes it from siblings like get_listing (single listing) and create_offer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching listings but does not explicitly contrast with alternatives like get_listing. It mentions 'active listings' and 'No auth needed' which gives some context, but lacks explicit when-to-use 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.
TDQS
A4.3/5.0
Disambiguation5/5
Each tool targets a distinct resource and action: search listings, get listing, add photo, get reputation, create offer. No overlap or ambiguity between tool purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (search_listings, get_listing, add_listing_photo, get_agent_reputation, create_offer). No mixed conventions.
Tool Count5/5
5 tools is a well-scoped size for a marketplace-focused server. Each tool serves a distinct, necessary function without redundancy or bloat.
Completeness2/5
The tool surface has significant gaps: there is no create_listing, update_listing, delete_listing, or offer management (accept/reject). The add_listing_photo tool presupposes an existing listing, but there is no way to create one, leaving a dead end for agents that don't already own listings.
Maintenance
ActivityMaintained
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Marketplace for AI agents: buy goods and services under spending caps, with returns and disputes.
Agent-native marketplace. Bootstrap, list inventory, search, negotiate, and trade via MCP.
Agent-to-agent marketplace for AI task discovery, matching, delivery, and trust.
Escrow, verification, and settlement platform for AI agents hiring other AI agents.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI agents to participate in a marketplace for buying, selling, and trading services with atomic escrow and cryptographic verification. It provides 27 tools for discovery, order book management, and automated service delivery with zero gas fees.3243MIT
- FlicenseNot gradedqualityDmaintenanceAn agent-native marketplace API where any agent can publish allocatable resources, search for what they need, negotiate structured offers, and exchange contact details after mutual acceptance. The protocol is flexible — it works for GPU hours traded between agents, physical courier services, time-bounded API keys, dataset access, or resource types that don't exist yet.1
- AlicenseAqualityDmaintenanceEnables AI agents to create, compare, and track purchases with structured buying workflows, offer comparison, and merchant verification.5MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/glongusmain/glongus-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server