Skip to main content
Glama
alexar76

aimarket-mcp

by alexar76
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

πŸ“– Read-only mirror. aimarket-mcp 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-mcp β€” ecosystem MCP gateway

🌐 English Β· Русский Β· EspaΓ±ol Β· FranΓ§ais Β· δΈ­ζ–‡ Β· Glossary

🟒 Just want to try the marketplace? Install nothing.

Paste https://modelmarket.dev/mcp into your MCP client and you have market_search

  • market_invoke against the live hub, with a few free trial invokes per caller and a signed receipt for each β€” no wallet, no key, no install. β†’ docs/hosted-mcp-endpoint.md

Install this package when you want the other three tools (web_fetch, web_search, metis_verify), or want to point the market tools at a hub of your own.

One MCP gateway. Five hardened tools. Shared by Metis, ARGUS, and the ecosystem.

Transport: stdio (aimarket_mcp/stdio_server.py) for Glama / Claude Desktop / Cursor, built with the official Model Context Protocol Python SDK (mcp, FastMCP). Also ships Streamable-HTTP on :9090 for self-hosted deployments (aimarket-mcp-http, Docker Compose).

Item

Location

MCP entrypoint (stdio)

aimarket_mcp/stdio_server.py

MCP gateway (HTTP)

aimarket_mcp/server.py

Tool handlers + security

aimarket_mcp/tools.py, aimarket_mcp/security.py

Glama / Docker (stdio)

Dockerfile, glama.json

Self-host HTTP

Dockerfile.http, docker-compose.yml

Compatible hosts: Claude Desktop, Cursor, Glama, and any MCP client that supports stdio or Streamable-HTTP.

Tools

Tool

What it does

Hardening

web_fetch

Fetch a URL, return main text (readability-lite)

SSRF-guarded; output sanitized + <untrusted>-wrapped

web_search

Live DuckDuckGo search β†’ top snippets

output sanitized + <untrusted>

metis_verify

Metis cognition + verification envelope

returns answer + verify_score / verified gate

market_search

Discover priced capabilities on an AIMarket hub

free; no wallet, key or channel; the hub lists only what it can execute

market_invoke

Run one on the hub's free trial tier

returns the signed receipt nonce; reports the hub's 402 verbatim when the allowance is spent

Example β€” buy a GAIA Open-Meteo reading

market_search_tool(intent="gaia weather open-meteo")
market_invoke_tool(
  capability_id="gaia.weather.read@v1",
  product_id="gaia.gateway",
  source_hub="https://iot.modelmarket.dev",
  # input JSON with device_id om-wx-01 β€” see tool schema / hub docs
)

Or the same HTTP the tool wraps:

curl -s -X POST "${AIMARKET_HUB_URL:-https://modelmarket.dev}/ai-market/v2/invoke" \
  -H 'Content-Type: application/json' \
  -H 'X-AIMarket-Sandbox-Visitor: vis_mcp_om_wx' \
  -d '{"capability_id":"gaia.weather.read@v1","product_id":"gaia.gateway",
       "source_hub":"https://iot.modelmarket.dev","input":{"device_id":"om-wx-01"}}'

That is the easy path (trial/sandbox). Proving an external wallet paid on-chain is a separate escrow flow (openChannel β†’ DebitAuthorization β†’ hub debit/settle) β€” see docs/onchain-journal.md Β§3l–§3m and gaia/docs/LIVE-RELAYS.md.

Why a gateway (not per-agent tools): generic capabilities are written once; the security core lives in one audited place. Ecosystem-specific capabilities live in their own MCP servers (aimarket-oracle-gateway, aimarket-plugins).

Related MCP server: qsearch

Configure (env)

var

meaning

AIMARKET_METIS_URL

Metis verify API base (default https://metis.modelmarket.dev)

AIMARKET_METIS_KEY

optional bearer for Metis verify

AIMARKET_SEARCH_URL

DuckDuckGo HTML endpoint override

AIMARKET_HUB_URL

AIMarket hub for market_search / market_invoke (default https://modelmarket.dev)

AIMARKET_SANDBOX_VISITOR

Trial identity for market_invoke; random per install, set it to keep an allowance across reinstalls

AIMARKET_MCP_KEY

HTTP only β€” bearer auth key

AIMARKET_MCP_PRODUCTION

HTTP only β€” 1 requires AIMARKET_MCP_KEY (fail-closed)

AIMARKET_MCP_RATE

HTTP only β€” requests/min per key/IP (default 120)

AIMARKET_MCP_PORT

HTTP only β€” listen port (default 9090)

Run (stdio β€” Glama / Claude Desktop)

Claude Desktop (mcpServers entry) β€” no clone, no working directory to get wrong:

{
  "mcpServers": {
    "aimarket-mcp": {
      "command": "uvx",
      "args": ["aimarket-mcp"]
    }
  }
}

uvx fetches the published package and runs its aimarket-mcp console script, which is the stdio server. With the package already installed, "command": "aimarket-mcp" and no args does the same thing.

From a checkout, for development:

pip install -e .
python -m aimarket_mcp.stdio_server

Run (HTTP β€” self-host)

pip install -e .
AIMARKET_MCP_KEY=sk-... AIMARKET_MCP_PRODUCTION=1 aimarket-mcp-http   # :9090
# or: docker compose up -d   (uses Dockerfile.http)

Cursor / Claude (Streamable HTTP)

{
  "mcpServers": {
    "aimarket-web": {
      "type": "streamable-http",
      "url": "http://127.0.0.1:9090/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_AIMARKET_MCP_KEY"
      }
    }
  }
}

Publish on Glama

Listing: glama.ai/mcp/servers/alexar76/aimarket-mcp

Same pattern as aimarket-oracle-gateway (working on Glama): repo-root glama.json + Dockerfile + python -m aimarket_mcp.stdio_server.

Field

Value

Dockerfile

Dockerfile (from repo β€” not Glama debian/uv template)

Command

python -m aimarket_mcp.stdio_server

Placeholder parameters

{}

Pinned SHA

empty (latest)

Do not use the auto-generated debian:trixie-slim + uv sync + mcp-proxy -- aimarket-mcp template β€” that was the broken HTTP/ENOENT path.

Consumers

  • Metis β€” enable the preset:

    enable_mcp_tools: true
mcp_ecosystem_presets: [aimarket-web]

  • ARGUS β€” add the server to argus.config.json mcpServers (see that repo).

Test

pip install -e '.[dev]' && pytest -q

Glama

Glama ignores repo Dockerfiles β€” set Build steps in admin/dockerfile:

["bash scripts/glama_install.sh"]

CMD: [".venv/bin/python", "-m", "aimarket_mcp.stdio_server"]. Pin main or tag glama-build (not a fixed SHA). Details: docs/GLAMA.md.

Registries

Registry

Listing

Glama

glama.ai/mcp/servers/alexar76/aimarket-mcp

Official MCP Registry

io.github.alexar76/aimarket-mcp β€” server.json + GitHub Actions

PyPI

pip install aimarket-mcp

GitHub Releases

github.com/alexar76/aimarket-mcp/releases

Available Tools

3 tools
metis_verify_toolA

Run Metis cognition + verification on an input; returns answer plus verify_score/verified.

Calls the Metis /v1/verify API. Response includes machine-readable metadata [verify_score=… status=… route=… verified=…] so agents can fail-closed when confidence is insufficient. Configure AIMARKET_METIS_URL and optional AIMARKET_METIS_KEY.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesQuestion or task for Metis to answer through its cognition + verification envelope. Example: 'Is 2+2=4?' or 'Summarize the MIT license in one sentence.'
routeNoMetis cognition depth: fast (single pass), thinking (deeper), council (multi-agent, default), agent (tool-using). Higher routes cost more latency but improve verify_score.council

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

No annotations, so description carries burden. It explains the response includes machine-readable metadata and fail-closed behavior. Could add more on error handling.

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?

Three short sentences, front-loaded with purpose, efficient.

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 schema and output schema, description adds configuration and behavioral notes. No major 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 coverage is 100% so baseline is 3. Description adds little beyond schema: mentions route enum options but schema already enumerates them.

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 it runs Metis cognition and verification, returns answer plus verify_score/verified, and names the API endpoint. Siblings are web tools, so no confusion.

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?

Describes configuration and that it calls a specific API, but does not explicitly state when to use or not use versus alternatives. However, 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.

web_fetch_toolA

Fetch a web page by URL and return its main text content.

SSRF-hardened (scheme allow-list, private-IP block, per-redirect re-validation, size cap). Output is sanitized, role-marker stripped, and wrapped in <untrusted>…</untrusted> before it can reach a model β€” safe for agent consumption with explicit untrusted marking.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic http(s) URL to fetch. Private IPs, localhost, and non-http schemes are rejected (SSRF guard). Example: https://example.com/docs/guide
max_charsNoMaximum characters of extracted main text to return (default 20000).

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

Despite no annotations, the description provides substantial behavioral details: SSRF hardening (scheme allow-list, private-IP block, per-redirect re-validation), size cap, output sanitization, role-marker stripping, and untrusted wrapping. This goes beyond the basic fetch 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?

Two sentences, no redundant words. The purpose is stated first, then detailed safety and output handling. Every sentence provides essential information.

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's moderate complexity, the description covers core functionality, safety constraints, and output format. With an output schema present, return value explanation is unnecessary. Could mention caching or rate limits but not critical.

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% with clear descriptions. The tool description reinforces safety context (SSRF, size cap) that adds value beyond the schema, especially for the url parameter which warns about private IPs.

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 'Fetch a web page by URL and return its main text content', with a specific verb and resource. It distinguishes itself from sibling tools (web_search_tool for searching, metis_verify_tool for verification) by focusing on direct URL fetching.

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?

While the description implies usage for fetching known web pages, it does not explicitly contrast with sibling tools or provide when-to-use vs when-not-to-use guidance. The agent must infer from context.

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

web_search_toolA

Search the web for current facts and return the top result snippets.

Uses DuckDuckGo HTML results. Output is sanitized and wrapped <untrusted> like web_fetch. Prefer this over guessing when the answer depends on recent events or documentation.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNatural-language search query for live web facts. Example: 'PyPI aimarket-metis release date'

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

Discloses backend (DuckDuckGo HTML) and output sanitization/wrapping (<untrusted>). No annotations provided, so description carries burden; it gives useful context but omits potential rate limits or result count limits.

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?

Three sentences, no wasted words. Front-loaded with purpose. Every sentence adds value.

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?

Tool is simple with one param. Description covers backend, output format, and usage context. Output schema exists but description doesn't detail full return structure; however, 'top result snippets' and wrapping info suffice.

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?

Single parameter 'query' has schema description (100% coverage). Description adds an example and context ('natural-language', 'live web facts'), enhancing meaning 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?

Description clearly states verb ('search'), resource ('web'), and output ('top result snippets'). Differentiates from siblings by recommending use over guessing for recent events.

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?

Explicitly states when to prefer this tool ('when the answer depends on recent events or documentation'). Lacks explicit exclusions or when not to use, but the positive guidance is clear.

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.

  1. 3 tool updatesv0.1.0
    • First observedmetis_verify_tool
    • First observedweb_fetch_tool
    • First observedweb_search_tool
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: verification, web fetching, and web search. No overlap or ambiguity between them.

Naming Consistency4/5

All tool names follow a `[modifier]_[verb]_tool` pattern, but the modifiers mix a specific name ('metis') with a category ('web'). While predictable, the inconsistency in modifier types reduces consistency slightly.

Tool Count2/5

With only three tools and a server name implying an AI market domain, the tool count feels too small. The tools do not cover typical market-related operations, making the set feel incomplete for its apparent scope.

Completeness1/5

The tool set lacks any market-specific functionality (e.g., listing products, getting details) despite the server name. The generic web utilities and a specialized verification API do not form a coherent coverage of the implied domain.

Maintenance

ActivityNo data
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • qsearch

    theYahia
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to perform web searches with full content retrieval and multi-engine provenance, including trust scoring and local corpus persistence, via MCP integration.
    3
    2
    Apache 2.0

  • MyWebSearch MCP

    iuiu-py
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to perform unified web research through a single MCP server, including search, page fetching, recursive crawling, document parsing, YouTube transcript extraction, and deep multi-query research.
    2
    -