This server provides pay-per-use access to IBM Granite AI foundation models via the x402 protocol, billed in USDC on Solana — no IBM Cloud account required.
Get started (free) (ibm_granite_getting_started): Retrieve an overview of available tools, pricing, the x402 payment flow, setup requirements, and example calls — no payment needed.
Conversational AI (ibm_granite_chat): Send multi-turn chat conversations to IBM Granite instruct models with configurable temperature and token limits (up to 50 messages). Cost: $0.02 USDC/call.
Code assistance (ibm_granite_code): Generate, review, refactor, explain, test, or document code across any programming language. Cost: $0.025 USDC/call.
Text embeddings (ibm_granite_embed): Generate vector embeddings for 1–64 texts (up to 8,000 chars each), suitable for RAG, semantic search, and clustering. Cost: $0.005 USDC/call.
Document analysis (ibm_granite_analyze): Perform structured analysis of documents (contracts, reports, emails, etc.) to extract entities, sentiment, risk signals, summaries, and next steps. Supports general, contract, financial, technical, medical, and sentiment modes. Cost: $0.04 USDC/call.
Time-series forecasting (ibm_granite_forecast): Run zero-shot forecasting using IBM Granite TTM on 64–1024 data points, forecasting up to 96 steps ahead. Suitable for revenue, traffic, sensor, energy, and financial data. Cost: $0.05 USDC/call.
Enables pay-per-use AI model calls with USDC micropayments settled on the Solana blockchain.
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., "@@three-ws/ibm-x402-mcp write a Python script to download a web page"
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 that exposes IBM Granite foundation models as pay-per-use tools via the x402 payment protocol. End users pay USDC on Solana per call — no IBM Cloud account of their own. The server operator supplies IBM credentials (
WATSONX_*) and a receiving Solana wallet (MCP_SVM_PAYMENT_ADDRESS); callers supply only USDC. One free tool (ibm_granite_getting_started) explains prices and the flow before any payment.
Built by three.ws. Community-built and not affiliated with IBM.
An MCP client (Claude Desktop, Claude Code, Cursor, or an agent) connects to this server.
The client calls a tool — e.g. ibm_granite_chat.
Without an x402 payment payload, the server returns a 402 PaymentRequired envelope quoting the USDC price and the Solana receiving address.
The client signs a Solana USDC transfer and retries with the payment in _meta["x402/payment"].
The server verifies and settles the payment via the facilitator, calls IBM watsonx.ai, and returns the result with a settlement receipt in _meta["x402/payment-response"].
x402-capable MCP clients handle this loop automatically.
Related MCP server: ntriq-agentshop
npm install @three-ws/ibm-x402-mcpRun it directly with npx (no install needed):
MCP_SVM_PAYMENT_ADDRESS=<your-solana-wallet> \
WATSONX_API_KEY=<ibm-api-key> \
WATSONX_PROJECT_ID=<watsonx-project-id> \
npx @three-ws/ibm-x402-mcpOr install globally for the ibm-x402-mcp binary on your PATH:
npm install -g @three-ws/ibm-x402-mcpWith Claude Code, one command (as an end user paying per call, no env vars needed):
claude mcp add ibm-granite-x402 -- npx -y @three-ws/ibm-x402-mcpServer operators add -e MCP_SVM_PAYMENT_ADDRESS=... -e WATSONX_API_KEY=... -e WATSONX_PROJECT_ID=... before the --.
Or wire the server into your MCP client config (claude_desktop_config.json, Cursor's mcp.json):
{
"mcpServers": {
"ibm-x402": {
"command": "npx",
"args": ["-y", "@three-ws/ibm-x402-mcp"],
"env": {
"MCP_SVM_PAYMENT_ADDRESS": "your-solana-wallet-address",
"WATSONX_API_KEY": "your-ibm-cloud-api-key",
"WATSONX_PROJECT_ID": "your-watsonx-project-id"
}
}
}
}Inspect the tool surface with the MCP Inspector:
npx -y @modelcontextprotocol/inspector npx @three-ws/ibm-x402-mcpTool | What it does | Price |
| Overview, prices, and the x402 payment flow. No payment or IBM account required. | Free |
| Conversational AI via IBM Granite (default | $0.02 USDC |
| Code generate, review, refactor, explain, test, document. | $0.025 USDC |
| Batch text embeddings for RAG, search, and clustering (1–64 texts). | $0.005 USDC |
| Structured document analysis: entities, sentiment, risk flags, summary, next steps. | $0.04 USDC |
| Zero-shot time-series forecasting via IBM Granite TTM (Tiny Time Mixer). | $0.05 USDC |
Every tool is a read-only model-inference call — nothing on your machine or in any account is modified — and declares MCP tool annotations (readOnlyHint, openWorldHint, idempotentHint) so clients can reason about side effects before paying.
ibm_granite_chat — messages (required: 1–50 { role, content } pairs), model, max_new_tokens (1–4096, default 1024), temperature (0–2, default 0.7).
ibm_granite_code — task (required: generate/review/refactor/explain/test/document), prompt (required), language, context.
ibm_granite_embed — inputs (required: 1–64 texts, ≤8000 chars each), model.
ibm_granite_analyze — document (required), analysis_type (general/contract/financial/technical/medical/sentiment, default general), language.
ibm_granite_forecast — timestamps (required: 64–1024 ISO-8601, uniform cadence, oldest first), values (required: 64–1024 numbers, same length), freq (required: pandas cadence, e.g. 1h, 1D), prediction_length (1–96), label.
// ibm_granite_chat
{
"messages": [
{ "role": "system", "content": "You are an expert data engineer." },
{ "role": "user", "content": "Design a lakehouse schema for IoT sensor telemetry." }
],
"max_new_tokens": 1024,
"temperature": 0.7
}
// ibm_granite_code
{ "task": "review", "prompt": "def calculate_roi(revenue, cost): return revenue / cost", "language": "Python" }
// ibm_granite_embed
{ "inputs": ["enterprise data governance", "cloud-native AI pipeline", "real-time analytics"] }
// ibm_granite_analyze
{ "document": "This Software License Agreement is entered into between...", "analysis_type": "contract" }
// ibm_granite_forecast (timestamps/values must be 64–1024 points; abbreviated here)
{ "timestamps": ["2025-01-01T00:00:00Z", "...", "2025-03-05T00:00:00Z"], "values": [12500, "...", 13200], "freq": "1D", "prediction_length": 14, "label": "daily_revenue_usd" }This server uses the x402 protocol for micropayments:
Client calls a tool without payment → 402 PaymentRequired with the USDC amount and Solana address.
Client builds and signs a Solana USDC transfer transaction.
Client retries with the signed tx in _meta["x402/payment"].
Server verifies and settles via the configured facilitator (default PayAI).
Server calls IBM watsonx.ai and returns the result with _meta["x402/payment-response"] (settlement receipt).
MCP Client (Claude Desktop / Cursor / agent)
│ tools/call (with x402 payment in _meta)
▼
ibm-x402-mcp (stdio MCP server)
│ verify + settle USDC on Solana
├──► x402 facilitator (default https://facilitator.payai.network)
│
│ inference call with IAM Bearer token
└──► IBM watsonx.ai (us-south.ml.cloud.ibm.com)
└── IBM Granite 3 8B Instruct / Embedding / TTMNode.js >= 20.
A Solana wallet address to receive USDC (MCP_SVM_PAYMENT_ADDRESS).
IBM Cloud credentials: an API key (create one) and a watsonx.ai project id (Project → Manage → General → Project ID), or a deployment space id.
Variable | Required | Default |
| yes | — |
| yes | — |
| yes (or | — |
| alternative to | — |
| no |
|
| no |
|
| no |
|
| no | three.ws fee payer |
| no |
|
Regional hosts: us-south, eu-de, eu-gb, jp-tok, au-syd, ca-tor — e.g. https://eu-de.ml.cloud.ibm.com.
@three-ws/ibm-watsonx-mcp — the same IBM Granite tools driven by your own IBM Cloud credentials (no x402, no per-call payment).
Homepage: https://three.ws
Changelog: https://three.ws/changelog
License: Apache-2.0 — see LICENSE
All rights reserved. See LICENSE.
Structured document analysis powered by IBM Granite: extract entities, sentiment, risk signals, a concise summary, and recommended next steps from any text (contracts, reports, emails, code reviews, etc.). Returns a machine-readable JSON analysis. No IBM Cloud account required — pay $0.04 USDC per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | The document, report, email, or text to analyze. | |
| language | No | Document language hint (e.g. "Spanish", "French"). Defaults to auto-detect. | |
| analysis_type | No | Analysis focus: general (universal), contract (legal terms, obligations), financial (metrics, risks, forecasts), technical (architecture, issues), medical (clinical entities, findings), or sentiment (tone, emotions). | general |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description adds that the tool returns structured JSON, costs $0.04 per call, and requires no account. No contradictions. It provides useful behavioral context beyond annotations.
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 sentences, front-loaded with the main purpose, followed by cost and output format. No wasted words.
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?
The description explains return contents (entities, sentiment, etc.), compensating for lack of output schema. It also addresses pricing and authentication (no account needed). Together with sibling names, it provides sufficient context for an agent to decide to use the tool.
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 100% (all parameters have descriptions). The description reinforces the tool's capabilities but does not add new parameter-level detail beyond what the schema already provides. Baseline 3 is appropriate.
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 specifies the verb 'extract entities, sentiment, risk signals, a concise summary, and recommended next steps', the resource 'any text', and distinguishes from siblings like ibm_granite_chat or ibm_granite_code. It is clear and specific.
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 mentions input types (contracts, reports, emails) and cost/payment method, providing context for when to use. However, it does not explicitly state when not to use or compare with alternatives, though the sibling list provides implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chat completion powered by IBM Granite foundation models (default: ibm/granite-3-8b-instruct). Send a conversation as role/content message pairs and receive the assistant reply with token usage. No IBM Cloud account required — pay $0.02 USDC per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Override the Granite model id (e.g. ibm/granite-3-2b-instruct). Defaults to ibm/granite-3-8b-instruct. | |
| messages | Yes | Conversation history. Must include at least one user message. | |
| temperature | No | Sampling temperature (0 = deterministic). Defaults to 0.7. | |
| max_new_tokens | No | Maximum tokens to generate. Defaults to 1024. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld hints. The description adds valuable information: payment model ($0.02 USDC via x402), that no IBM Cloud account is needed, and that token usage is returned. These details go beyond what annotations provide.
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 two sentences, efficiently conveying the core functionality, input format, output, and pricing without redundancy. It is well-structured and front-loaded.
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 the tool's complexity (four parameters with full schema descriptions), the description covers the essential context: input/output nature, default model, and payment. It lacks detail on response format but annotations and schema fill in gaps adequately.
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 100%, so baseline is 3. The description adds context by mentioning 'role/content message pairs' and default model, which clarifies the use of the messages array and model parameter beyond schema descriptions.
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 clearly states it is a chat completion tool using IBM Granite models. While it doesn't explicitly differentiate from sibling tools, the names of siblings (analyze, code, embed, forecast, getting_started) imply distinct tasks, so the purpose is sufficiently clear.
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 does not provide guidance on when to use this tool versus alternatives or when not to use it. It lacks explicit context for selection criteria among siblings or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Code generation, review, refactoring, and explanation via IBM Granite instruct models. Provide a task type and code/prompt; receive the generated or reviewed code with explanation. No IBM Cloud account required — pay $0.025 USDC per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Code task: generate (new code from description), review (bugs/security), refactor (quality), explain (plain language), test (unit tests), or document (add docstrings). | |
| prompt | Yes | For "generate": describe what to build. For all others: paste the code to process. | |
| context | No | Additional context: architecture notes, constraints, or example usage. | |
| language | No | Target programming language (e.g. "TypeScript", "Python", "Rust"). Optional for explain/review. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost ($0.025 USDC per call) and account requirement (no IBM Cloud account needed) beyond annotations. Annotations already indicate read-only and open world, and description adds useful behavioral context without contradiction.
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 concise sentences with clear front-loading of purpose, followed by usage and cost. No wasted words; every sentence adds essential 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?
Covers task types, prompt usage, cost, and account requirement. Lacks detailed return value specification, but the mention of 'receive code with explanation' suffices given no output schema. Could mention rate limits or max response length, but overall adequate.
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 100%, so baseline is 3. Description adds extra value by summarizing that prompt differs per task (code for review/refactor/explain, description for generate) and stating the output type (code with explanation).
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?
Description clearly states the tool handles code generation, review, refactoring, and explanation via IBM Granite. Lists specific task types, distinguishing it from sibling tools like ibm_granite_chat or ibm_granite_analyze.
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?
Provides clear context on when to use (for code tasks) and what to provide (task and prompt). Lacks explicit exclusions or alternatives, but the mention of 'Provide a task type and code/prompt' gives enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate embedding vectors for one or more texts using IBM Granite (default: ibm/granite-embedding-278m-multilingual). Returns one float array per input, suitable for semantic search, RAG retrieval, and similarity scoring. Up to 64 texts per call. No IBM Cloud account required — pay $0.005 USDC per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Override the embedding model id (e.g. ibm/granite-embedding-125m-english). Defaults to ibm/granite-embedding-278m-multilingual. | |
| inputs | Yes | Texts to embed. 1–64 strings per call, up to 8,000 characters each. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) declare safety and idempotency. The description adds context: uses IBM Granite model with a specified default, returns float arrays per input, and notes no IBM Cloud account required. This is non-contradictory and enhances transparency.
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 two sentences, front-loading the essential purpose and key constraints. Every word adds value; there is no redundancy or 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?
For a simple embedding tool with full schema and annotations, the description covers return type (float array), limits, cost, default model, and use cases. No output schema exists, but the description adequately explains output. Completeness is high.
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 100%, so the schema already documents both parameters. The description adds the default model string and reiterates limits (1-64 texts, 8000 characters), which is helpful but only marginally extends schema information. Baseline 3 is appropriate.
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 uses precise language: 'Generate embedding vectors for one or more texts' and specifies the default model, output format (float array), and use cases (semantic search, RAG retrieval, similarity scoring). It clearly distinguishes from sibling tools like ibm_granite_chat or ibm_granite_code.
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 states the maximum number of texts (64) and the cost model ($0.005 USDC per call via x402), providing practical usage guardrails. It does not explicitly mention when not to use or alternatives, but the sibling names make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Zero-shot time-series forecasting via IBM Granite TTM (Tiny Time Mixer). Provide a numeric series with ISO-8601 timestamps and a cadence, receive the forecast horizon. No training required. Suitable for revenue, traffic, sensor, energy, and financial series. No IBM Cloud account required — pay $0.05 USDC per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| freq | Yes | Cadence of the series as a pandas-style frequency string. Examples: 1min, 5min, 15min, 30min, 1h, 2h, 4h, 12h, 1D, 1W, 1ME. | |
| label | No | Human label for the series (e.g. "daily_revenue_usd"). Returned in output for traceability. | |
| values | Yes | Numeric series aligned to timestamps, oldest to newest. Must be the same length as timestamps. | |
| timestamps | Yes | ISO-8601 timestamps at a uniform cadence, oldest to newest (e.g. ["2025-01-01T00:00:00Z", ...]). | |
| prediction_length | No | Number of steps to forecast ahead. Defaults to the model horizon (typically 96 for 1h data). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint, which are consistent with the forecasting and payment model. The description adds value by specifying the zero-shot nature, the underlying model (TTM), and the cost per call, providing behavioral context beyond annotations. No contradiction found.
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 three sentences long, with the key action in the first sentence. It efficiently covers purpose, required inputs, and additional context (cost, suitability) without redundancy.
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 the complexity of time-series forecasting and full schema coverage, the description provides sufficient context: model type, input requirements, and cost. While it mentions receiving the forecast horizon, it could elaborate on output format, but overall it is complete for an agent to use.
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 has 100% parameter description coverage. The description adds context by summarizing the required inputs (timestamps, values, cadence) and mentioning the default prediction length (typically 96 for 1h data), which aids understanding beyond schema.
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 explicitly states 'Zero-shot time-series forecasting' using IBM Granite TTM, clearly identifying the verb (forecast) and resource (time series). It distinguishes from sibling tools that focus on analysis, chat, code, embedding, or getting started.
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 mentions when to use (suitable for revenue, traffic, sensor, energy, financial series) and that no training or IBM Cloud account is required. It implies alternatives are not needed but does not explicitly state 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.
FREE — start here. Returns an overview of this server: the IBM Granite tools available, their per-call USDC prices, how the x402 pay-per-call flow works, setup requirements, and runnable example calls. No payment required. Call this first to orient before invoking a paid tool.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Which part to return. Defaults to "overview" (everything). Use "pricing", "payment", "tools", or "setup" to focus. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds that it is free and returns an overview, which is consistent. It provides useful context beyond annotations (e.g., no payment needed) but does not disclose additional side effects.
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 two sentences, front-loaded with 'FREE — start here,' and every word adds value. No redundancy or unnecessary detail.
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 orientation tool with no required parameters and a clear enum, the description fully covers what the tool returns (overview, prices, payment, tools, setup, examples). No output schema is needed as the return content is described.
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 covers 100% of parameters with descriptions, including enum values and defaults. The tool description repeats the enum values but adds no new meaning beyond what the schema already 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?
The description clearly states it returns an overview of server tools, prices, payment flow, setup, and examples. It explicitly positions itself as the starting point, distinguishing from sibling paid tools by being free and introductory.
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 explicitly says 'start here' and 'Call this first to orient before invoking a paid tool,' providing clear guidance on when to use this tool. It also notes that no payment is required, reinforcing its role.
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.1.0ibm_granite_analyzeibm_granite_chatibm_granite_codeibm_granite_embedibm_granite_forecastibm_granite_getting_startedEach tool has a uniquely defined purpose (analysis, chat, code, embedding, forecasting, and getting started) with no ambiguity between them. An agent can easily distinguish which tool to invoke.
All tool names follow the consistent pattern 'ibm_granite_<action>', using snake_case and a clear verb describing the operation. This pattern is uniform across all 6 tools.
The server has 6 tools, which is well-scoped for a focused MCP server offering IBM Granite model capabilities. Each tool covers a distinct use case without being overwhelming or insufficient.
The tool set covers common AI tasks (chat, code, analysis, embeddings, forecasting) and includes a getting started guide. Minor gaps like model customization or batch operations are absent, but core functionality is complete for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pay-per-use IBM Granite AI via x402: chat, code, embeddings, forecasting. USDC on Base or Solana.
BridgeNode — x402 pay-per-request AI inference. OpenAI-compatible API + MCP, Solana USDC, gas-free.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nirholas/ibm-x402-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server