Skip to main content
Glama
openvecta

@openvecta/mcp

by openvecta
OverviewSchemaRelated ServersScoreDiscussions
JavaScript

@openvecta/mcp

MCP server for OpenVecta — call OpenVecta inference models (OpenAI-compatible, USDC-settled on Solana) as tools from any MCP client: Claude Desktop, Cursor, Windsurf, agent kits.

npm

Tools

Tool

What it does

Auth needed

list_models

Catalog + per-1M-token USDC pricing, modality, flat fee

none (public)

estimate_cost

Estimate a call's USDC cost before running it

none (public)

chat

Chat completion on any model

keyed or x402

embed

Embeddings

keyed only

Related MCP server: x402-gateway-mcp

Two auth modes (auto-detected from env)

KEYED — set OPENVECTA_API_KEY (ov_sk_...). Uses your prepaid balance / free tier. Simplest; works everywhere. (Wins if both are set.)

X402 — set SOLANA_PRIVATE_KEY (base58). Pays per call in USDC from that wallet via the x402 protocol — no account, no key. Chat only. ⚠️ Real funds move. Test on devnet first (SOLANA_NETWORK=devnet).

Install

No install step needed — npx fetches it on demand:

npx -y @openvecta/mcp

Add to Claude Desktop / Cursor

Config file — Claude Desktop: %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS).

Keyed:

{
  "mcpServers": {
    "openvecta": {
      "command": "npx",
      "args": ["-y", "@openvecta/mcp"],
      "env": { "OPENVECTA_API_KEY": "ov_sk_live_..." }
    }
  }
}

x402 — pay per call, no account (test on devnet first!):

{
  "mcpServers": {
    "openvecta": {
      "command": "npx",
      "args": ["-y", "@openvecta/mcp"],
      "env": {
        "SOLANA_PRIVATE_KEY": "base58-secret-key",
        "SOLANA_NETWORK": "devnet"
      }
    }
  }
}

Restart the client, then ask e.g. "list the OpenVecta models" or "use OpenVecta's glm-5.2 to explain Solana".

Env reference

Var

Default

Notes

OPENVECTA_API_KEY

—

ov_sk_ key → KEYED mode

SOLANA_PRIVATE_KEY

—

base58 secret → X402 mode

SOLANA_NETWORK

mainnet

mainnet | devnet

SOLANA_RPC_URL

per-network

override RPC

OPENVECTA_BASE_URL

https://api.openvecta.com/v1

staging / self-host

How x402 mode works

Uses the official @x402/fetch client (@x402/svm ExactSvmScheme + a @solana/kit signer) to wrap fetch: the request hits /v1/chat/completions, gets a 402 challenge, the library builds + signs the USDC transfer from your wallet, resends with the payment header, and OpenVecta settles + serves. chat requires max_tokens here (it bounds the pre-authorization ceiling; defaults to 1024 if omitted).

The public model catalogue and per-token pricing are readable without auth at /.well-known/x402.

Security: never commit a private key. For production/agents, load it from a secrets manager, not a config file. list_models / estimate_cost need no auth.

Build from source

npm install
npm run build   # -> dist/index.js

License

MIT

Available Tools

3 tools
chatA

Run a chat completion on an OpenVecta model (OpenAI-compatible). Pays via your configured mode (prepaid key or x402 per-call). Returns the reply + token usage.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYesModel id, e.g. 'glm-5.2' (see list_models)
messagesYesOpenAI-style chat messages
max_tokensNoMax output tokens (REQUIRED in x402 mode)
temperatureNo

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description must handle behavioral disclosure. It mentions payment modes (prepaid key or x402 per-call) and that the tool returns token usage, which adds useful context. However, it does not state whether the tool is read-only, modifies state, or has any side effects, leaving some behavioral gaps.

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 consists of two concise sentences that cover the tool's purpose, payment mode, and return value. Every sentence adds value without unnecessary detail, making it easy for an agent to quickly understand the tool.

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 absence of an output schema, the description adequately explains the return value (reply + token usage). It also mentions payment configuration, which is important context. However, it could briefly note that the tool mimics an OpenAI completion endpoint for agents familiar with that API.

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?

The input schema already describes 3 of 4 parameters (75% coverage), so the baseline is 3. The tool description does not add any additional parameter-specific meaning beyond what the schema provides. For example, it does not mention temperature or provide details on parameter usage that would raise the score.

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 runs a chat completion on an OpenVecta model, which is OpenAI-compatible. It specifies the verb 'run' and the resource 'chat completion', distinguishing it from siblings like embed and estimate_cost. The return value (reply + token usage) is explicitly mentioned, making the purpose precise.

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?

The description gives a clear context for use (running chat completions) but does not provide explicit guidance on when to use this tool over alternatives or when not to use it. The sibling tools have different purposes, so confusion is minimal, but no exclusion criteria or prerequisites are stated.

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

embedA

Create embeddings for text with an OpenVecta embeddings model (e.g. 'text-embedding-3-small'). Keyed mode only (x402 is chat-only).

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesText or array of texts
modelYesEmbeddings model id

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description should disclose behavioral traits. It mentions keyed mode only and excludes x402 for chat, but does not state whether the tool modifies data, has rate limits, or returns specific output structure.

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 concise sentences with no redundant information. Essential details are front-loaded, and every sentence provides value.

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?

The tool has 2 required params and no output schema. The description does not mention what the tool returns (e.g., embedding vectors), which would help the agent understand the result. It covers purpose and mode but omits output details.

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. The description adds value by giving an example model name and specifying keyed mode, but does not elaborate on parameter constraints or format beyond the schema.

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 that the tool creates embeddings for text using an OpenVecta model, with an example. It also distinguishes from sibling tool 'chat' by mentioning keyed mode and that x402 is chat-only.

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?

The description implies that this tool is for embeddings and not for chat (x402 is excluded), but it does not explicitly state when to use it versus 'estimate_cost' or provide clear when-not-to-use conditions.

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

estimate_costA

Estimate the USDC cost of a call before running it: input/output token counts priced against the model's live rate (+ flat per-call fee).

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYes
input_tokensYes
output_tokensNo

TDQS

A4/5.0
Behavior3/5

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

No annotations exist, so the description must convey behavior. It mentions estimation based on live rates, implying a read-only operation. However, it does not explicitly state that no side effects occur or that it queries an external rate. This is adequate but not comprehensive.

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 a single sentence that efficiently conveys the tool's purpose and key details. Every word earns its place, and it is front-loaded with the core action.

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 no output schema and three simple parameters, the description provides sufficient context for typical use. It lacks explicit mention of the output format (e.g., numeric cost value), but overall completeness is high for a straightforward estimation tool.

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 0%, so the description must add parameter meaning. It mentions 'input/output token counts' and 'model's live rate', mapping to the three parameters. However, it does not explain the model parameter's allowed values, the default for output_tokens, or any constraints beyond the schema. This adds some but not full value.

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 estimates USDC cost of a call before execution, using token counts and live model pricing. It distinguishes from siblings (chat, embed) which are execution tools, not estimation.

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 indicates use before running a call, providing clear context. It does not explicitly state when not to use it or mention alternatives, but siblings are different in nature, making usage context sufficiently 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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.1
    • First observedchat
    • First observedembed
    • First observedestimate_cost
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool serves a distinct purpose: chat for text generation, embed for text embeddings, and estimate_cost for cost estimation. No overlap in functionality.

Naming Consistency4/5

Names are descriptive verbs or verb-noun combos, but 'chat' and 'embed' are single words while 'estimate_cost' uses an underscore, a minor inconsistency.

Tool Count4/5

Three tools is minimal but appropriate for the focused scope of running AI model operations and cost estimation. The count is on the low side but not insufficient.

Completeness4/5

Covers the core workflows: chat completions, embeddings, and cost estimation. Missing model listing or management, but the surface is complete for basic usage.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/openvecta/mcp'

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