What can you do with this server?

This is a read-only MCP server for accessing and auditing SimpleShop accounting data — it cannot create, update, delete, or mutate any records. Authentication * simpleshop_login / simpleshop_test_login: Sign in at runtime using direct credentials, a Prefab UI form, or a localhost web form; validate and persist credentials locally. Find Documents (simpleshop_find_documents) Search across document types (invoices, proformas, receipts, orders, tax documents, credit documents, expenses, quotes, etc.) with rich filters: * Date ranges (created, paid, due, taxable supply), payment/cancellation/archive state * Document flags (e.g., paid, canceled, has_vat, oss), currency, customer ID, tag, number series, free-text search * Batch fetch by explicit IDs, cursor-based pagination, optional PDF resource links Download Document PDFs (simpleshop_download_documents) Batch-download PDF renderings (up to 100 at a time), choosing stamped or unstamped variants; returns base64-encoded content with SHA-256 hash and per-document success/error results. Find Products (simpleshop_find_products) Search or batch-fetch products by type (ebook, video, membership, physical goods, ticket, course, voucher, service, etc.), with optional variant details and archived product inclusion. Get Product Sales (simpleshop_get_product_sales) Retrieve normalized "who bought" sales export data for specific products — buyer info, purchase totals, payment method, coupon, invoice number, and custom fields; supports row limits and optional raw CSV. Get Metadata (simpleshop_get_metadata) Retrieve reference data for filtering and classification: document types, product types, flags, payment methods, number series, and tags. Privacy Controls * Customer/buyer PII is redacted by default across all tools. * Set include_customer_pii: true to access names, emails, addresses, company/VAT IDs, and raw payloads.

How do I use SimpleShop MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SimpleShop MCP Find invoices from last month" 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.

SimpleShop MCP

by mikz

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

SimpleShop MCP

Read-only FastMCP server for SimpleShop accounting data.

This server exposes a small MCP tool surface for AI agents that need to audit SimpleShop documents, download document PDFs, inspect products, and review product sales exports before copying data into another accounting system.

It is intentionally read-only. It does not create, update, delete, pay, cancel, send, or mutate SimpleShop records.

Install as a Plugin

simpleshop-mcp ships as a Claude Code / Cowork plugin. In either client:

/plugin marketplace add mikz/simpleshop-mcp
/plugin install simpleshop-mcp@simpleshop-mcp

Credentials are configured outside MCP tool calls. Local stdio mode reads SIMPLESHOP_LOGIN and SIMPLESHOP_API_KEY from environment or .env; remote HTTP deployments should inject the same names from the platform secret manager.

Requirements on the host machine:

uvx on PATH (install with uv)
Python 3.13 (uvx will fetch one if missing)

Related MCP server: fiken-mcp

Features

Find SimpleShop documents across invoices, proformas, receipts, orders, tax documents, and related document types.
Default document search is payment-reconciliation oriented: invoices, advance invoices, proformas, payment requests, tax documents, and receipts. Orders are explicit because they often duplicate invoice payment keys.
Batch-download document PDFs, with per-document success/error results.
Find products through the SimpleShop product API.
Fetch and normalize SimpleShop "who bought" product sales exports.
Return metadata useful for accounting filters, including document types, product types, flags, payment methods, number series, and tags.
Use one reusable HTTP client initialized through FastMCP lifespan dependency injection.
Redact customer/buyer PII by default, with explicit opt-in for full data.

Tool Surface

simpleshop_test_login
simpleshop_find_documents
simpleshop_download_documents
simpleshop_find_products
simpleshop_get_product_sales
simpleshop_get_metadata

simpleshop_test_login takes no arguments and is the quickest way to confirm the current credentials work. It reports not_logged_in when none are available.

Finder tools use a concrete query object with a required mode field:

{
  "query": {
    "mode": "search"
  }
}

or:

{
  "query": {
    "mode": "by_ids",
    "ids": [123]
  }
}

by_ids mode requires IDs and ignores stray search filters so retry calls remain robust when an agent carries over defaults from schema discovery. For simpleshop_find_documents, omitting document_types defaults to settlement/accounting documents used for payment reconciliation. Pass document_types: ["order"] explicitly for order workflows. Paid-date search uses paid_from and paid_to, which map to SimpleShop's date_paid filter expression; pass the same date to both fields for an exact paid day. Document results include normalized payment_instructions for intended receiving-account details and document paid state. They do not include matched bank transaction evidence.

See TOOLS.md for full schemas, examples, cursor behavior, and privacy controls. The design rationale is in DESIGN.md.

Privacy Defaults

Normal document and sales responses redact customer/buyer PII by default.

Set include_customer_pii: true only when the caller actually needs names, emails, phone numbers, addresses, company IDs, VAT IDs, custom sales fields, raw document payloads, or raw CSV exports.

Raw fields are guarded:

include_raw requires include_customer_pii: true.
include_raw_csv requires include_customer_pii: true.
simpleshop_get_product_sales supports max_sales_rows, total_rows, returned_rows, and truncated for bounded exports.
Public money values are returned as fixed two-decimal strings. When payment instruction account fields are present, they are normalized under payment_instructions.

Requirements

Python >=3.13,<3.14
uv
Optional: mise for pinned local tool versions

The project currently pins:

fastmcp[apps]==3.3.0
httpx==0.28.1
pydantic==2.13.4
pydantic-settings==2.14.1

Installation

Using mise:

mise install
mise run sync

Using uv directly:

uv sync --locked

Configure credentials through a local .env, environment variables, or your remote runtime secret manager. No MCP tool accepts or persists credentials. To create a local .env:

cp .env.example .env

Credential format:

SIMPLESHOP_LOGIN=user@example.com
SIMPLESHOP_API_KEY=replace-with-api-key

Optional:

SIMPLESHOP_BASE_URL=https://api.simpleshop.cz/2.0/
SIMPLESHOP_TIMEOUT_SECONDS=30

Do not commit .env or real API credentials.

Running

The plugin's MCP server config lives inline in .claude-plugin/plugin.json and uses uvx --from ${CLAUDE_PLUGIN_ROOT} simpleshop-mcp. No .mcp.json is committed at the repo root, so workspace-mode Claude Code sessions in this directory do not try to launch the server. Run it with one of the commands below instead.

Run the MCP server over stdio:

uv run --locked simpleshop-mcp

With the installed script:

uv run --locked simpleshop-mcp

Run directly from GitHub with uvx:

SIMPLESHOP_LOGIN=user@example.com \
SIMPLESHOP_API_KEY=replace-with-api-key \
uvx --from git+https://github.com/mikz/simpleshop-mcp.git simpleshop-mcp

For local development with FastMCP reload:

mise run mcp

MCP Client Configuration

Example MCP server config:

[mcp_servers.simpleshop]
command = "uv"
args = ["run", "--locked", "simpleshop-mcp"]
cwd = "/path/to/simpleshop-mcp"

If you use mise:

[mcp_servers.simpleshop]
command = "mise"
args = ["run", "mcp"]
cwd = "/path/to/simpleshop-mcp"

Run from GitHub without cloning:

[mcp_servers.simpleshop]
command = "uvx"
args = ["--from", "git+https://github.com/mikz/simpleshop-mcp.git", "simpleshop-mcp"]

Pass credentials through your MCP host environment, not through committed config.

Development

Run tests:

uv run --locked pytest

Run lint:

uv run --locked ruff check .

Check formatting on touched files:

uv run --locked ruff format --check src tests

Live smoke tests are intentionally opt-in because they use real SimpleShop credentials and may expose account data in local logs if run carelessly. See E2E.md.

Repository Layout

src/
  client.py        SimpleShop HTTP client
  models.py        Pydantic models for normalized and raw API data
  normalization.py Document normalization helpers
  server.py        FastMCP server and exposed tools
DESIGN.md          Tool design rationale
TOOLS.md           Tool reference and examples
E2E.md             Live smoke-test guidance
tests/             Offline unit and contract tests

License

MIT. See LICENSE.

Available Tools

5 tools

simpleshop_download_documentsC

Batch-download the PDF rendering of SimpleShop documents.

ParametersJSON Schema

Name	Required	Description	Default
`documents`	Yes
`max_bytes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`documents`	Yes

TDQS

C2.3/5.0

Behavior1/5

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

No annotations provided and the description contains no behavioral details (e.g., failure modes, rate limits, authentication needs, or output format). The description fails to disclose any traits beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise (one sentence) but at the expense of essential detail. Every sentence should earn its place; this one is too sparse to be adequately informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of batch-downloading documents (multiple parameters, output schema exists but unmentioned, constraints like max 100 items), the description is grossly incomplete. No information on result format, error handling, or limits.

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

Parameters1/5

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

Schema description coverage is 0%. The description does not explain what the 'documents' array items represent, the meaning of 'variant' (with/without stamp), or the purpose of 'max_bytes'. With only 2 parameters, this omission is critical.

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 (batch-download) and resource (PDF rendering of SimpleShop documents), distinguishing it from sibling tools like 'simpleshop_find_documents'.

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 guidance on when to use this tool vs. siblings such as 'simpleshop_find_documents' or 'simpleshop_find_products'. No context on prerequisites or exclusions.

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

simpleshop_find_documentsB

Find SimpleShop documents by search filters or explicit document IDs.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Object query. Use {"mode":"search"} for the newest matching documents, or {"mode":"by_ids","ids":[...]} for explicit document IDs.

Output Schema

ParametersJSON Schema

Name	Required	Description
`documents`	Yes
`next_cursor`	No
`control_totals`	No
`raw_documents`	No

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the basic operation, omitting details like pagination, sorting, filtering semantics, or whether the operation is read-only. The description adds minimal behavioral context beyond the schema.

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 a single concise sentence with no waste. It is front-loaded with the essential purpose, though the structure could include key parameter modes for clarity.

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?

Given the tool's complexity (many filters, pagination, and an output schema), the description is adequate but not complete. It explains the two modes but omits details like sorting, pagination, and flag filtering, which are documented in the schema. The high schema coverage mitigates the gaps.

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 100% (the complex input schema includes descriptions for most parameters). The tool description does not add anything beyond what the schema already provides, meeting 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 clearly states the tool's purpose: 'Find SimpleShop documents by search filters or explicit document IDs.' It uses a specific verb ('Find') and resource ('SimpleShop documents'), and distinguishes from sibling tools like `simpleshop_download_documents` (which downloads) and `simpleshop_find_products` (which finds products).

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?

The description provides no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. It lacks context for selecting between 'search' and 'by_ids' modes beyond what the schema example shows.

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

simpleshop_find_productsB

Find SimpleShop products by search filters or explicit product IDs.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Object query. Use {"mode":"search"} to list/filter products, or {"mode":"by_ids","ids":[...]} for explicit product IDs.

Output Schema

ParametersJSON Schema

Name	Required	Description
`products`	Yes
`next_cursor`	No

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, description should disclose behaviors like pagination, rate limits, or authentication, but only states basic operation. No behavioral details beyond what the name implies.

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?

Single sentence, no wasted words, purpose immediately clear.

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?

Output schema exists, so return values need not be explained. However, the dual-mode operation is only hinted at; schema fills in details, but description could summarize mode behavior more clearly.

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 description adds no extra parameter meaning beyond high-level mention of filters and IDs. Baseline 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 clearly states the tool finds SimpleShop products using search filters or explicit IDs. It distinguishes from sibling tools like find_documents and get_metadata.

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 guidance on when to use this tool versus alternatives, no when-not-to-use or prerequisites provided.

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

simpleshop_get_metadataC

Return SimpleShop metadata useful for filtering and accounting classification.

ParametersJSON Schema

Name	Required	Description	Default
`include_payment_methods`	No
`include_number_series`	No
`include_tags`	No
`include_document_types`	No
`include_product_types`	No
`include_flags`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`payment_methods`	No
`number_series`	No
`tags`	No
`document_types`	No
`product_types`	No
`flags`	No

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility. It only states 'Return... metadata', implying a read operation, but gives no details on side effects, authentication needs, rate limits, or output behavior. This is insufficient for a tool with 6 parameters.

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?

The description is one short sentence, which is concise but lacks structure. It is not front-loaded with the most critical information (e.g., parameters). Every sentence earns its place, but more content is needed to be helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, 6 parameters without descriptions, and no output schema details in the description, the tool is severely under-documented. The description does not explain what metadata categories are, how to use the boolean flags, or what the return value contains.

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

Parameters1/5

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

Schema description coverage is 0% and the description does not mention any parameters. Each of the 6 boolean parameters controls inclusion of metadata categories, but the description adds no meaning beyond the schema defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Return') and resource ('SimpleShop metadata'), and hints at its purpose ('useful for filtering and accounting classification'). It is distinct from sibling tools which focus on documents and products, but could be more explicit about what metadata covers.

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?

The description offers no guidance on when to use this tool versus alternatives, no when-not-to-use conditions, and no mention of prerequisites or context. The single sentence only provides a general purpose.

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

simpleshop_get_product_salesC

Return SimpleShop product sales using the 'who bought' export.

ParametersJSON Schema

Name	Required	Description	Default
`product_ids`	Yes
`scope`	No		api_default
`max_sales_rows`	No	Maximum normalized sales rows returned per product.
`include_customer_pii`	No	Return buyer name/contact/address fields. Defaults to redacted.
`include_raw_csv`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`products`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only says 'using the who bought export', which hints at a format but does not disclose side effects, permissions, rate limits, or whether it is read-only. Additional details like return structure or pagination are missing.

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?

The description is a single short sentence, which is concise and front-loaded. However, it omits important details that could be added without significant length, making it somewhat under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters and an output schema, the description should explain the overall behavior, scope options, and what the 'who bought' export entails. It does not, leaving the agent with insufficient context to use the tool correctly.

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?

Schema description coverage is only 40%, with two parameters having descriptions. The tool description adds no additional meaning to any parameters, failing to compensate for the undocumented ones such as product_ids, scope, and include_raw_csv.

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 'Return' and the resource 'SimpleShop product sales', and references the specific 'who bought export' mechanism. This distinguishes it from sibling tools which deal with documents or products.

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 guidance is provided on when to use this tool versus alternatives or when not to use it. The description only states what it does without any contextual recommendations.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0May 15, 2026
- First observedsimpleshop_download_documents
- First observedsimpleshop_find_documents
- First observedsimpleshop_find_products
- First observedsimpleshop_get_metadata
- First observedsimpleshop_get_product_sales

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct action and resource: downloading documents, finding documents, finding products, getting metadata, and getting product sales. No overlap in purposes.

Naming Consistency5/5

All tools follow a consistent 'simpleshop_verb_noun' pattern in snake_case (e.g., download_documents, find_products), making them predictable and easy to understand.

Tool Count5/5

With 5 tools covering key retrieval and reporting functions for documents, products, metadata, and sales, the set is well-scoped and not overly sparse or bloated.

Completeness3/5

The tools cover search, download, and metadata retrieval but lack any creation, update, or deletion operations. For a shop system, this is a notable gap, though it may be sufficient for a read-only reporting server.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
Mini AccountantOAuth
app.miniaccountant
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
E-commerce & Retail Finance ERP Systems
1
HubSpotOAuth
com.hubspot.app
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Customer Data Platforms Databases Marketing
3
ORANO MCP Server
io.github.infotik
Read-only MCP server exposing a user ORANO library to their own AI agent.
Note Taking Knowledge & Memory Search
1

Related MCP Servers

moneys3-mcp
Finance ERP Systems
hlebtkachenko
A
license
C
quality
D
maintenance
MCP server for connecting AI clients to the Money S3 accounting system via GraphQL API, enabling operations on invoices, contacts, stock, banking, payroll, and more.
Updated 5 months ago (2026-04-13 06:16 UTC)
61
2
MIT
fiken-mcp
Finance ERP Systems
heim
A
license
B
quality
D
maintenance
A read-only MCP server that exposes Fiken accounting API's 61 GET endpoints as tools for AI assistants to query accounting data.
Updated 6 months ago (2026-03-21 19:28 UTC)
61
8
3
MIT
Shopify MCP
chatterjeearjun
A
license
A
quality
C
maintenance
A read-only MCP server that lets AI assistants answer Shopify store operations questions via tools like get_shop, list_products, get_product, and list_orders.
Updated 2 months ago (2026-07-20 03:16 UTC)
4
MIT
local-tools-mcp-server
fenhuayue
F
license
A
quality
C
maintenance
A read-only MCP server that enables AI assistants to search files, list directories, retrieve system info, and get file metadata on the local file system.
Updated 2 months ago (2026-07-20 09:22 UTC)
4
-

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/mikz/simpleshop-mcp'

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

SimpleShop MCP

Install as a Plugin

Features

Tool Surface

Privacy Defaults

Requirements

Installation

Login And Configuration

Running

MCP Client Configuration

Development

Repository Layout

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API