What can you do with this server?

This server packages AIMarket capabilities into self-hosted MCP server products, generating all deployment artifacts needed to run them in Claude Desktop, Cursor, Glama, or any stdio MCP client. * package_capability — The primary tool; assembles a complete MCP server package for a given AIMarket capability, returning a Docker image name, full MCP manifest (server metadata + tool definitions), subscription/pricing tiers, and a client connection string. * generate_dockerfile — Generates a ready-to-build Dockerfile for the packaged MCP server, which you can write to disk and run docker build on to produce the deployable image. * generate_claude_desktop_config — Generates a claude_desktop_config.json snippet (an mcpServers block) that registers the dockerized MCP server with Claude Desktop or any compatible MCP host — just merge it into your existing config and restart the host. All three tools share core inputs: a capability_id (e.g. translate.multi@v2), a product_id, a human-readable name, an optional description, an optional JSON Schema for inputs, and an optional container registry namespace.

Which integrations are available for this server?

Generates Dockerfile templates and Docker run configurations for containerized deployment of packaged MCP servers.

aimarket-mcp-packager

by alexar76

Overview Schema Related Servers Score Discussions

Python

Hybrid

📖 Read-only mirror. aimarket-plugins is published from the canonical AI-Factory monorepo. Pull requests are not accepted — any commit pushed here is overwritten by scripts/mirror_satellites.sh on the next sync. 🐞 Found a bug or have a request? Please open an issue.

AIMarket Hub Plugins

Ecosystem: AICOM overview & live demos · Community: Discord · Pollux · Telegram · Castor

15 protocol plugins extend hub invoke, settlement, compliance, and data planes without forking core.

Verifiable math lives in the separate oracles monorepo (Platon, Chronos, Murmuration, Lumen, …) — listed on the hub like any capability. aimarket-reputation scores sellers; Lumen oracle supplies PageRank/EigenTrust-style trust artifacts agents can invoke and audit.

Install

PyPI (top-5): docs/install.md

Package	PyPI status
`aimarket-hub`	✅ 3.0.0
`aimarket-tee`, `aimarket-channels`, `aimarket-reputation`	✅ 2.0.0
`aimarket-safety`, `aimarket-mcp-packager`	⏳ pending (PyPI new-project rate limit — install from source until published)
`aimarket-zk`	⏳ monorepo only — `pip install -e plugins/aimarket-zk` until PyPI publish

Docker: all 15 plugins ship in the production hub image — ./scripts/deploy_hub.sh from the factory monorepo.

Source: pip install -e plugins/aimarket-tee after cloning this repo.

Related MCP server: Test MCP Server

TEE Escrow

Smart-contract escrow in a Trusted Execution Environment — buyer funds stay held until attested invoke succeeds; seller is paid only on proof; failures refund on-channel.


What	`aimarket-tee` + provenance + safety → hold → invoke → release/refund
Why	Micropay scale with both-side protection — no human escrow desk
Deep dive	docs/killer-feature-tee-escrow.md · Ecosystem capabilities

MCP server — `aimarket-mcp-packager`

One of the 15 plugins is a full Model Context Protocol server — stdio transport, built on the official MCP Python SDK. aimarket-mcp-packager turns any AIMarket capability into a self-hosted MCP product (Docker image, MCP manifest, and a ready claude_desktop_config.json) that runs in Claude Desktop, Cursor, Glama, or any stdio MCP client.


Run	`python plugins/aimarket-mcp-packager/mcp_stdio_server.py` (stdio) · `docker build` from repo root
Tools	`package_capability` · `generate_dockerfile` · `generate_claude_desktop_config`
Registry	Listed on Glama (score badge above) — see `aimarket-mcp-packager/` for the server, `glama.json`, and Dockerfile

MCP server — `aimarket-oracle-gateway` (standalone repo)

A second MCP server ships as its own satellite repo alexar76/aimarket-oracle-gateway for Glama indexing. aimarket-oracle-gateway exposes Platon randomness, Chronos VDF, and LUMEN reputation as agent-callable tools — pay-per-call over AIMarket, every result independently verifiable.


Run	`AIMARKET_HUB_URL=https://modelmarket.dev python mcp_stdio_server.py`
Tools	`get_random` · `compute_vdf` · `get_reputation_scores` · `list_oracle_capabilities` · …
Registry	— `glama.json` + `Dockerfile`

Plugin index

Plugin	Role
aimarket-safety	Pre-invoke policy, signed reject
aimarket-tee	TEE attestation, escrow hooks
aimarket-provenance	W3C VC invoke receipts
aimarket-reputation	Scores + stake bonds
aimarket-channels	USDT channel lifecycle
aimarket-auction	Price discovery
aimarket-orchestrator	Multi-capability plans
aimarket-data-cap	Data-capability packaging
aimarket-dataset	Dataset listings
aimarket-mcp-packager	MCP server (stdio) — package capabilities as Docker + MCP manifest + Claude Desktop config
aimarket-nft	Capability NFTs
aimarket-personas	Seller personas
aimarket-promo	Promotions
aimarket-streaming	Streaming invoke
aimarket-zk	ZK cohort proofs

Hub loads plugins from aimarket-hub/plugins/ at runtime. Monorepo copies under plugins/ are the source-of-truth for docs and tests.

Demo

Live: https://modelmarket.dev/plugins/demo
Docs: https://github.com/alexar76/aimarket-plugins/blob/main/docs/install.md

Repo	Role
aimarket-hub	Loads plugins at invoke time
oracles	Verifiable math capabilities (separate repo)
aicom	AI-Factory monorepo
dioscuri	Twin community agents — MNEMOSYNE Q&A

Community

The DIOSCURI twins answer questions from synced GitHub docs.

Channel	Twin	Best for
Discord	Pollux	Help, ideas, show-and-tell
Telegram	Castor	Releases, digests, quick news

Ecosystem map: Alien Monitor · AICOM

Available Tools

3 tools

generate_claude_desktop_configA

Generate a claude_desktop_config.json snippet for the packaged MCP server.

Takes the same capability inputs as package_capability and returns the mcpServers entry that registers the docker-run MCP server with Claude Desktop (or any MCP host that reads this config format).

Returns: A JSON object (string) containing an mcpServers block — merge it into the user's existing claude_desktop_config.json and restart the host.

Example: generate_claude_desktop_config( capability_id="translate.multi@v2", product_id="prod-translate", name="Lyra Translator", )

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Human-readable display name for the packaged MCP server, shown to end users in MCP clients such as Claude Desktop (e.g. 'Lyra Translator').
`registry`	No	Container registry namespace for the built image. Defaults to 'aifactory'. Set your own org/namespace to publish under a different account (e.g. 'ghcr.io/acme').	aifactory
`product_id`	Yes	Owning product ID on the AIMarket hub, e.g. 'prod-translate'. Used to namespace the Docker image and the MCP manifest.
`description`	No	One- or two-sentence summary of what the capability does. Surfaced in the MCP manifest and the Claude Desktop config. Optional but strongly recommended — it becomes the tool description in the generated server.
`input_schema`	No	JSON Schema object describing the capability's input. For example, an object with a required string property 'text'. Omit or pass null for a schema-less capability.
`capability_id`	Yes	Fully-qualified capability identifier to package, e.g. 'translate.multi@v2'. This is the single capability the generated MCP server will expose as a tool.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states the tool generates and returns a JSON snippet, but does not mention any side effects, permissions, or state changes. For a generation tool, this is adequate but could be more explicit about its non-destructive nature.

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 front-loaded with the main purpose, followed by usage context and an example. It is relatively concise, though the example repeats parameter names already defined. No superfluous sentences.

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?

Given the tool has 6 parameters and no annotations, the description covers the return value format and usage. The output schema exists, so not detailing its structure is acceptable. It is complete enough for an agent to understand when and how to use it.

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%, yet the description adds value: it groups parameters as 'same inputs as package_capability', explains the 'description' parameter's purpose in the generated config, and notes the default for 'registry'. This goes beyond 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 clearly states the verb 'generate' and the resource 'claude_desktop_config.json snippet'. It distinguishes from siblings by noting it takes the same inputs as 'package_capability' but returns an 'mcpServers' entry, not a Dockerfile or packaged capability.

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?

It explains the tool's output (mcpServers entry) and relation to 'package_capability', implying when to use it (after packaging). It also provides an example. Does not explicitly exclude scenarios, but context is clear enough.

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

generate_dockerfileA

Generate a ready-to-build Dockerfile for the packaged MCP server.

Takes the same capability inputs as package_capability and returns the Dockerfile text that builds the self-hosted MCP server image for it.

Returns: The Dockerfile contents as plain text — write it to Dockerfile and run docker build to produce the image named in package_capability's docker_image field.

Example: generate_dockerfile( capability_id="translate.multi@v2", product_id="prod-translate", name="Lyra Translator", )

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Human-readable display name for the packaged MCP server, shown to end users in MCP clients such as Claude Desktop (e.g. 'Lyra Translator').
`registry`	No	Container registry namespace for the built image. Defaults to 'aifactory'. Set your own org/namespace to publish under a different account (e.g. 'ghcr.io/acme').	aifactory
`product_id`	Yes	Owning product ID on the AIMarket hub, e.g. 'prod-translate'. Used to namespace the Docker image and the MCP manifest.
`description`	No	One- or two-sentence summary of what the capability does. Surfaced in the MCP manifest and the Claude Desktop config. Optional but strongly recommended — it becomes the tool description in the generated server.
`input_schema`	No	JSON Schema object describing the capability's input. For example, an object with a required string property 'text'. Omit or pass null for a schema-less capability.
`capability_id`	Yes	Fully-qualified capability identifier to package, e.g. 'translate.multi@v2'. This is the single capability the generated MCP server will expose as a tool.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns Dockerfile contents as plain text and directs the user to write to file and run docker build. It also references the `docker_image` field from `package_capability`, which adds context. No behavioral surprises or contradictions.

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 paragraph with a Returns section and an example. It is efficient and front-loaded, but could be slightly more structured (e.g., bullet points for clarity). No wasted sentences.

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?

Given the simplicity of the tool, the description sufficiently covers the return value and usage pattern. It references the sibling's output field, which adds necessary cross-tool context. The tool has an output schema (implied) and the description explains the return format adequately.

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%, so baseline is 3. The description adds some context (e.g., takes same inputs as `package_capability` and shows an example) but does not significantly enhance the meaning of individual parameters beyond what the schema already provides.

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?

Clearly states it generates a Dockerfile for a packaged MCP server, with explicit reference to the sibling tool `package_capability` for context. The verb 'generate' combined with the resource 'Dockerfile' is specific and distinguishable from siblings.

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?

Indirectly implies usage after `package_capability` by referencing its inputs, but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned; however, sibling tools have distinct purposes, so the need for guidance is moderate.

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

package_capabilityA

Build a complete self-hosted MCP server package for an AIMarket capability.

Use this first. It assembles everything needed to ship the capability as a standalone MCP server: the Docker image name, the MCP manifest (server + tool definition), subscription/pricing tiers, and a connection string.

Returns: A JSON object (string) with keys: - docker_image: the image name to build/run. - mcp_manifest: the full MCP manifest (server metadata + tools). - subscription_tiers: pricing tiers derived for the capability. - connection_string: how a client connects to the running server.

Example: package_capability( capability_id="translate.multi@v2", product_id="prod-translate", name="Lyra Translator", description="Translate text into multiple languages.", input_schema={"type": "object", "properties": {"text": {"type": "string"}}, "required": ["text"]}, )

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Human-readable display name for the packaged MCP server, shown to end users in MCP clients such as Claude Desktop (e.g. 'Lyra Translator').
`registry`	No	Container registry namespace for the built image. Defaults to 'aifactory'. Set your own org/namespace to publish under a different account (e.g. 'ghcr.io/acme').	aifactory
`product_id`	Yes	Owning product ID on the AIMarket hub, e.g. 'prod-translate'. Used to namespace the Docker image and the MCP manifest.
`description`	No	One- or two-sentence summary of what the capability does. Surfaced in the MCP manifest and the Claude Desktop config. Optional but strongly recommended — it becomes the tool description in the generated server.
`input_schema`	No	JSON Schema object describing the capability's input. For example, an object with a required string property 'text'. Omit or pass null for a schema-less capability.
`capability_id`	Yes	Fully-qualified capability identifier to package, e.g. 'translate.multi@v2'. This is the single capability the generated MCP server will expose as a tool.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It details return values (a JSON object with four keys) and provides an example. It does not mention side effects or destructive actions, but the tool appears to be a pure builder function without harmful consequences.

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 concise (three short paragraphs and an example), front-loaded with the main purpose, and structured with clear sections for returns and example. Every sentence adds value.

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 that an output schema exists (inferred from context), the description adequately explains the return structure. It covers all necessary aspects: parameter details, return format, and usage ordering relative to siblings.

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%, but the description adds significant value beyond schema: it explains the purpose of each parameter in context (e.g., 'the single capability the generated MCP server will expose as a tool' for capability_id) and includes a comprehensive example.

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 its purpose: 'Build a complete self-hosted MCP server package for an AIMarket capability.' It uses a specific verb ('Build') and resource ('self-hosted MCP server package'), and distinguishes from siblings by noting 'Use this first' and that it assembles everything needed.

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 explicitly says 'Use this first,' providing clear context for when to use it. It does not mention when not to use it or alternatives, but siblings are sufficiently different so no confusion arises.

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.

3 tool updatesv1.0.1Jun 18, 2026

Changedgenerate_claude_desktop_config12 fields changed

addedInput schema / properties / capability_id / description

Added value: +"Fully-qualified capability identifier to package, e.g. 'translate.multi@v2'. This is the single capability the generated MCP server will expose as a tool."

addedInput schema / properties / capability_id / examples

Added value: +[
+  "translate.multi@v2",
+  "summarize.long@v1"
+]

addedInput schema / properties / description / description

Added value: +"One- or two-sentence summary of what the capability does. Surfaced in the MCP manifest and the Claude Desktop config. Optional but strongly recommended — it becomes the tool description in the generated server."

addedInput schema / properties / description / examples

Added value: +[
+  "Translate text into multiple languages with one call."
+]

addedInput schema / properties / input_schema

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "JSON Schema object describing the capability's input. For example, an object with a required string property 'text'. Omit or pass null for a schema-less capability.",
+  "examples": [
+    {
+      "properties": {
+        "text": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "text"
+      ],
+      "type": "object"
+    }
+  ],
+  "title": "Input Schema"
+}

removedInput schema / properties / input_schema_json

Removed value: -{
-  "default": "{}",
-  "title": "Input Schema Json",
-  "type": "string"
-}

addedInput schema / properties / name / description

Added value: +"Human-readable display name for the packaged MCP server, shown to end users in MCP clients such as Claude Desktop (e.g. 'Lyra Translator')."

addedInput schema / properties / name / examples
```
Added value: +[
+  "Lyra Translator"
+]
```

addedInput schema / properties / product_id / description

Added value: +"Owning product ID on the AIMarket hub, e.g. 'prod-translate'. Used to namespace the Docker image and the MCP manifest."

addedInput schema / properties / product_id / examples
```
Added value: +[
+  "prod-translate"
+]
```

addedInput schema / properties / registry / description

Added value: +"Container registry namespace for the built image. Defaults to 'aifactory'. Set your own org/namespace to publish under a different account (e.g. 'ghcr.io/acme')."

addedInput schema / properties / registry / examples

Added value: +[
+  "aifactory",
+  "ghcr.io/acme"
+]

Changedgenerate_dockerfile12 fields changed

addedInput schema / properties / capability_id / description

Added value: +"Fully-qualified capability identifier to package, e.g. 'translate.multi@v2'. This is the single capability the generated MCP server will expose as a tool."

addedInput schema / properties / capability_id / examples

Added value: +[
+  "translate.multi@v2",
+  "summarize.long@v1"
+]

addedInput schema / properties / description / description

Added value: +"One- or two-sentence summary of what the capability does. Surfaced in the MCP manifest and the Claude Desktop config. Optional but strongly recommended — it becomes the tool description in the generated server."

addedInput schema / properties / description / examples

Added value: +[
+  "Translate text into multiple languages with one call."
+]

addedInput schema / properties / input_schema

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "JSON Schema object describing the capability's input. For example, an object with a required string property 'text'. Omit or pass null for a schema-less capability.",
+  "examples": [
+    {
+      "properties": {
+        "text": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "text"
+      ],
+      "type": "object"
+    }
+  ],
+  "title": "Input Schema"
+}

removedInput schema / properties / input_schema_json

Removed value: -{
-  "default": "{}",
-  "title": "Input Schema Json",
-  "type": "string"
-}

addedInput schema / properties / name / description

Added value: +"Human-readable display name for the packaged MCP server, shown to end users in MCP clients such as Claude Desktop (e.g. 'Lyra Translator')."

addedInput schema / properties / name / examples
```
Added value: +[
+  "Lyra Translator"
+]
```

addedInput schema / properties / product_id / description

Added value: +"Owning product ID on the AIMarket hub, e.g. 'prod-translate'. Used to namespace the Docker image and the MCP manifest."

addedInput schema / properties / product_id / examples
```
Added value: +[
+  "prod-translate"
+]
```

addedInput schema / properties / registry / description

Added value: +"Container registry namespace for the built image. Defaults to 'aifactory'. Set your own org/namespace to publish under a different account (e.g. 'ghcr.io/acme')."

addedInput schema / properties / registry / examples

Added value: +[
+  "aifactory",
+  "ghcr.io/acme"
+]

Addedpackage_capability

2 tool updatesv1.0.0Jun 8, 2026
- First observedgenerate_claude_desktop_config
- First observedgenerate_dockerfile

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: package_capability builds the package, generate_dockerfile produces the Dockerfile, and generate_claude_desktop_config outputs the config snippet. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (package_capability, generate_dockerfile, generate_claude_desktop_config), making them predictable and easy to understand.

Tool Count4/5

With 3 tools, the server is slightly small but well-scoped for its packaging purpose. Each tool serves a necessary step, and adding more would risk bloat.

Completeness4/5

The tool set covers the core packaging workflow: build the package, generate Dockerfile, and generate config. Minor gaps exist, such as lacking a validation or listing tool, but the main path is complete.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
clipkit A
dev.clipkit
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Multimedia Processing Image & Video Processing
15215

Related MCP Servers

MCP Server Example
Developer Tools Code Execution Autonomous Agents
alejandro-ao
A
license
B
quality
D
maintenance
An educational implementation of a Model Context Protocol server that demonstrates how to build a functional MCP server for integrating with various LLM clients like Claude Desktop.
Updated a year ago (2025-04-29 10:58 UTC)
1
163
MIT
Test MCP Server
Developer Tools App Automation
mokesmokane
F
license
Not graded
quality
D
maintenance
A dual-transport MCP server that exposes your API as tools to LLM clients, supporting both stdio transport for local clients like Claude Desktop and HTTP/SSE transport for remote clients like OpenAI's Responses API.
Updated a year ago (2025-10-10 14:12 UTC)
-
my-mcp-server2
Developer Tools Code Execution
kcbabo
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server built with FastMCP that features dynamic tool loading and modular management via a dedicated tool directory. It supports both stdio and HTTP transport modes, enabling efficient development and deployment of custom MCP tools.
Updated 7 months ago (2026-02-11 12:28 UTC)
-
routine-mcp
Developer Tools
rskmanz
F
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server built with the mcp-framework for developing and managing custom tools. It provides a structured foundation for building and integrating modular components like data processors and API clients into Claude Desktop.
Updated 7 months ago (2026-01-25 14:18 UTC)
12
-

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/alexar76/aimarket-plugins'

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

AIMarket Hub Plugins

Install

TEE Escrow

MCP server — aimarket-mcp-packager

MCP server — aimarket-oracle-gateway (standalone repo)

Plugin index

Demo

Related repos

Community

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

MCP server — `aimarket-mcp-packager`

MCP server — `aimarket-oracle-gateway` (standalone repo)