Provides tools for interacting with the Etsy Open API v3, enabling management of shops, listings, receipts, and seller data, including read-only and destructive operation safeguards.
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., "@etsy-mcp-server list my active listings"
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.
A Model Context Protocol server for the Etsy Open API v3.
All 105 published operations are reachable. Nothing is excluded, because there is nothing to exclude — Etsy's v3 API is entirely seller-facing, with no admin tier and no endpoint an ordinary app is structurally barred from. What varies is the OAuth scopes, and that is what this server surfaces.
MIT licensed.
npm install -g @nasdigitaluk/etsy-mcpRelated MCP server: Etsy MCP Server
Two modes. Pick one.
API key — the 32 public operations (taxonomy, listing lookups, shop and review reads):
{ "env": { "ETSY_KEYSTRING": "your-keystring" } }Seller — everything, and it refreshes itself:
{
"env": {
"ETSY_KEYSTRING": "your-keystring",
"ETSY_SHARED_SECRET": "your-shared-secret",
"ETSY_CREDENTIALS_FILE": "~/.etsy-mcp-credentials",
"ETSY_SHOP_ID": "12345678"
}
}Seed the credentials file once from your authorisation flow:
ETSY_ACCESS_TOKEN=...
ETSY_REFRESH_TOKEN=...
ETSY_TOKEN_EXPIRES_AT=1757260800000ETSY_SHOP_ID is optional; it just defaults the shop_id argument on the shop tools.
1. x-api-key wants both halves — keystring:shared_secret. The bare keystring returns 403 on every authenticated call, and the message reads exactly like a scope refusal: "Shared secret is required in x-api-key header." That sends you hunting through your app's scope grants for a problem that is in a header. This server always sends both.
2. Etsy rotates the refresh token on every refresh. The old one stops working the moment the new one is issued, so losing the new one breaks the chain permanently — the only fix is re-authorising in a browser. Running two MCP clients at once is completely normal; both refresh, both spend the same token, and whichever writes second saves one Etsy has already invalidated.
Here the refresh happens inside an exclusive lock, re-reads under the lock before spending anything (another process may have already done the work while this one waited), and the write is atomic (temp file, fsync, rename). There is a test asserting that three concurrent callers cause exactly one refresh.
Etsy's access control is entirely scope-shaped, and the scope table has one property worth knowing before you authorise anything:
Of the 13 DELETE operations, exactly ONE needs
listings_d— deleting a whole live listing. The other twelve ride on scopes you already hold in order to edit anything at all.
So declining listings_d makes the single catastrophic delete impossible at the OAuth layer while leaving every normal operation working. No other operation, of any method, needs it.
etsy_check_scopes reports this: what the whole API needs, what one operation needs, and — with held: true — what your token actually carries. The two together are what turn a 403 into a fix rather than a guess.
Scope distribution across the 105 operations:
Scope | Operations |
(none — public) | 32 |
| 21 |
| 16 |
| 12 |
| 11 |
| 7 |
| 3 |
| 2 |
| 1 |
| 1 |
Seven tools for 105 operations. Every tool name and description is paid for in the model's context window on every turn, used or not — 105 tools would not be a tool list, it would be a catalogue with worse ergonomics.
Tool | |
| Browse the catalogue. Start here. |
| Call any operation by id. |
| What a call needs, and what your token holds. |
| The authenticated user, including |
| Listings in a shop, by state. |
| One listing in full. Public. |
| Orders. Needs |
Of 105 operations: 64 read, 28 write, 13 destructive.
MCP_READ_ONLY=1 refuse anything that changes state
MCP_NO_DESTRUCTIVE=1 allow writes, refuse deletes⚠️ Worth knowing: etsy_call is one door onto all 105 operations, 13 of which are deletes, so it is classified destructive and MCP_READ_ONLY=1 refuses it outright. The dedicated read tools stay usable in that mode — including etsy_check_scopes, because Etsy's scope-introspection endpoint is a POST that changes nothing and is deliberately classified a read. Classifying it by its verb would have read-only mode refuse the one call that diagnoses a permission problem.
curl -o vendor/etsy-openapi.json https://www.etsy.com/openapi/generated/oas/3.0.0.json
npm run generate && npm testThe coverage test fails if Etsy publishes an operation the catalogue does not carry, so a stale catalogue is loud rather than silent.
npm test # 24 tests, incl. the refresh-concurrency one
SMOKE_ENV='{"ETSY_KEYSTRING":"x"}' npm run smoke # real MCP over stdio@nasdigitaluk/mcp-server-core.
MIT.
Call any Etsy operation by id. If it returns 403, check the scope it needs with etsy_check_scopes — Etsy's scope refusals read like permission errors.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| params | No | ||
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does offer a useful insight: Etsy scope refusals can masquerade as permission errors. But it fails to disclose that the tool can invoke mutating operations, requires authentication/scopes, or returns operation-dependent response shapes. These are material gaps for a generic dispatcher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the core purpose first, then add a targeted troubleshooting hint. There is no filler, restatement, or redundant detail. The structure is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic dispatch tool with no output schema and no annotations, this definition is incomplete. It omits how to obtain valid operation ids, how body and params should be shaped, what response variability to expect, and whether operations can have side effects. The 403 scope hint helps but leaves too many invocation details unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's silence. It only clarifies operation_id ('by id'). The body and params objects receive no explanation of how they correspond to Etsy API path, query, or body arguments. This is insufficient for an agent to confidently construct a request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Call'), a clear resource ('any Etsy operation'), and the key selection criterion ('by id'). This immediately distinguishes it from the sibling tools, which are named for specific operations (e.g., etsy_get_listing, etsy_list_receipts), making it clear this is the generic dispatcher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when an operation id is available and provides a conditional fallback to etsy_check_scopes on 403. However, it does not explicitly state when to prefer dedicated sibling tools over this generic call, nor does it mention discovering valid operation ids via etsy_list_operations. Normal selection guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which OAuth scopes the Etsy API needs, and what each one unlocks. Useful before authorising an app, and the fastest way to understand a 403. Pass an operation id to see what one call needs; pass held=true to ask Etsy what your token actually carries. The two together are what turn a 403 into a fix.
| Name | Required | Description | Default |
|---|---|---|---|
| held | No | Ask Etsy which scopes the current token holds. Needs a seller token. | |
| operation_id | No | Report on a single operation instead of the whole API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that held=true asks Etsy what the token actually carries and requires a seller token, and it frames the tool as diagnostic. It doesn't spell out rate limits or response shape, but for a check-style tool this is solid context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose, then when to use it, then how to use the parameters. Every sentence contributes to the diagnostic story with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two optional parameters and no output schema. The description covers purpose, use cases, and both parameters well. It doesn't explicitly describe the response format, but the output is reasonably inferable from 'which scopes' and 'what each one unlocks.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage, so the baseline is 3. The description's 'pass an operation id' and 'pass held=true' instructions reinforce the schema rather than adding new syntax or constraints. The 403-fix framing adds workflow context but no new parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens by defining exactly what the tool delivers: which OAuth scopes the Etsy API needs and what each scope unlocks. This distinguishes it from sibling tools like etsy_call or etsy_list_operations, which are about executing or listing operations rather than explaining scope requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit timing and diagnostic context: useful before authorizing an app and as the fastest way to understand a 403. It does not name sibling alternatives or state when not to use it, so it falls just short of the top anchor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One listing in full. Public — works without a seller token.
| Name | Required | Description | Default |
|---|---|---|---|
| includes | No | Comma-separated, e.g. Images,Shop,Inventory,Videos. | |
| listing_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the endpoint is public and does not require a seller token, which is valuable behavioral context. But with no annotations, it does not explicitly state whether the operation is read-only, mention rate limits, errors, or describe the response behavior beyond 'in full'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short phrases with no fluff—and front-loads the core purpose before the access note. It is a bit telegraphic, but every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-ID tool, the description covers the core purpose and public access, and the schema documents the optional 'includes' parameter. However, it lacks explicit usage guidance, response expectations, and any note about how 'includes' affects the returned detail, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'includes' is described in the schema, but 'listing_id' has only a type. The description adds no parameter-level meaning and does not compensate for the undocumented required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'One listing in full' clearly identifies the resource (a single listing) and the scope ('in full'), which distinguishes it from etsy_list_listings. It lacks an explicit verb like 'retrieve' or 'get', but the meaning is unambiguous from the name and phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching one complete listing rather than a list, and the note 'Public — works without a seller token' gives useful context. However, it does not explicitly state when to use this tool versus alternatives like etsy_list_listings or etsy_call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The authenticated Etsy user, including their user_id and shop_id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It communicates that the tool returns the authenticated user and includes two key fields, implying a read-only lookup, but it does not mention failure behavior, scope requirements, or response shape beyond those fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence front-loads the resource and the important returned fields with no filler or redundancy. Every word adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description covers the essential resource and return fields adequately. It is slightly thin on auth/scope expectations, but the low complexity makes this a reasonably complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so there is no parameter detail for the description to add. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource, 'authenticated Etsy user', and the specific fields returned, 'user_id' and 'shop_id', which makes it distinct from sibling tools like etsy_get_listing and etsy_list_receipts. It loses a point only because it is phrased as a noun phrase rather than an explicit verb like 'retrieves' or 'gets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as etsy_call or etsy_list_operations, and no mention of required authentication scopes or prerequisites. An agent must infer from the name and resource alone that this is the tool for fetching the current user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listings in a shop, filtered by state.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No | ||
| offset | No | ||
| shop_id | Yes | Your shop id. etsy_get_me returns it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that listings are filtered by state, which largely repeats the schema. It does not disclose pagination behavior, default state behavior, response shape, or any authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short, front-loaded phrase with no filler or redundant detail. However, it is a fragment rather than a full sentence, and the extreme brevity starts to undermine completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and no annotations, this description is under-specified. An agent cannot tell what happens when state is omitted, how pagination works, what fields are returned, or what errors may occur.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description does not compensate. It hints at shop_id ('in a shop') and state ('filtered by state'), but says nothing about limit or offset semantics, defaults, or how the state filter behaves when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('listings'), the scope ('in a shop'), and the key filter ('by state'). It is clear enough to distinguish from etsy_get_listing (single listing) and etsy_list_receipts (receipts), though it does not name those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool versus etsy_get_listing, etsy_list_receipts, or etsy_list_operations. The context is implied only by the resource name, with no explicit when to use or 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.
Browse all 105 operations in the Etsy Open API v3. Every one is reachable — Etsy's API is entirely seller-facing. Each entry names the OAuth scope it needs, which is what turns a 403 into something you can act on. Use this to find an operation id for etsy_call.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Filter by id, path, tag or summary — try 'listing', 'receipt', 'shipping'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It communicates that this is a read-oriented browse operation, that it covers the entire seller-facing Etsy API, and that each entry exposes the OAuth scope needed — actionable context for handling 403s. Exact output shape and pagination are not stated, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: purpose is front-loaded, the seller-facing scoping sentence gives useful context, and the final sentence points to the consuming tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter catalog tool with no output schema, this is nearly complete: it explains what the tool returns conceptually, why OAuth scopes matter, and how to use the result with etsy_call. The only gap is finer output-shape or pagination detail, which is not essential for selecting and invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single optional search parameter, so the baseline is 3. The description adds value by naming the fields it filters (id, path, tag, summary) and providing concrete examples ('listing', 'receipt', 'shipping'), going beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete action and countable resource: 'Browse all 105 operations in the Etsy Open API v3.' It clearly positions the tool as the operation catalog and ties it to the next step, 'find an operation id for etsy_call,' which distinguishes it from siblings like etsy_list_listings, etsy_get_listing, or etsy_call itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it: 'Use this to find an operation id for etsy_call.' It also gives helpful search direction by id, path, tag, or summary. It does not enumerate when-not-to-use conditions or name alternative siblings for comparison, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Orders in a shop. Needs transactions_r.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| shop_id | Yes | ||
| was_paid | No | ||
| was_shipped | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add one useful behavioral detail: the 'transactions_r' scope requirement. However, it does not explicitly state that this is a read-only list operation, nor does it cover pagination, rate limits, or response shape. The auth requirement adds value but the behavioral context remains thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and has no filler, but it is terse to the point of being elliptical. Both sentences contribute information, yet the phrase 'Orders in a shop' is not a complete sentence and could be clearer. It is concise but sacrifices expressiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is far from complete. It explains neither the filter parameters nor the return behavior, and it gives no selection context relative to siblings. The 'transactions_r' requirement is helpful, but it is the only contextual signal beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of shop_id, limit, offset, was_paid, or was_shipped. 'Orders in a shop' only hints at the shop_id parameter, while the boolean filters and pagination semantics are completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as orders/receipts within a shop, which aligns with the tool name 'list_receipts' and helps distinguish it from sibling tools that target listings or the current user. It lacks an explicit verb such as 'lists' or 'retrieves', but the resource and scope are clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage-related information is the required 'transactions_r' scope, which is a precondition rather than guidance on when to use this tool. It does not mention alternatives like etsy_list_listings, etsy_list_operations, or when a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0etsy_calletsy_check_scopesetsy_get_listingetsy_get_meetsy_list_listingsetsy_list_operationsetsy_list_receiptsMost tools map cleanly to distinct actions: list operations, call an operation, check scopes, get the user, list listings, get a listing, list receipts. The three API-introspection tools (etsy_list_operations, etsy_call, etsy_check_scopes) are adjacent in purpose but their roles—discover, execute, diagnose—are reasonably clear.
All tools share the etsy_ prefix and almost all follow an etsy_verb_noun pattern: list_operations, check_scopes, get_me, list_listings, get_listing, list_receipts. etsy_call is the only mild deviation since it is a bare verb, but it remains readable and consistent with the overall style.
Seven tools is well-scoped for an API wrapper: three plumbing tools handle operation discovery, execution, and scope diagnosis, while four convenience tools cover the most common seller-facing reads. The generic etsy_call prevents the surface from needing hundreds of individual endpoint tools.
The etsy_call tool can invoke any of the 105 Etsy Open API v3 operations, and etsy_list_operations makes those operations discoverable, so there are no unavoidable dead ends. The named convenience tools cover frequent read workflows, while writes and less common operations remain reachable through the generic dispatcher.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Full Spotify Web API coverage - albums, artists, playlists, player controls, and more.
Broad, OAuth-protected provider and financial-domain API tools for research agents.
Track expenses, budgets, balances, transfers, and multi-currency reports with OAuth-secured tools.
OAuth 2.1 short-link tools for AI agents with scoped tokens, approvals, audit logs, and revocation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/N-Graves/etsy-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
