What can you do with this server?

This MCP server lets you query and manage your Pricempire CS2 trader portfolio through an LLM agent, without requiring manual UI interaction. Key capabilities include: * Portfolio value & summary (get_portfolio_value): Total current value, 24h change, item count, invested amount, profit/loss, and ROI — per portfolio or combined. * List portfolio items (list_portfolio_items): Per-item details including current price, quantity, float, paint seed, stickers, category, average buy price, unrealized P/L, and ROI. Supports filtering by limit or minimum value. * Cross-marketplace price lookup (get_item_prices): Current prices for one or more CS2 items across Buff163, Steam, CSFloat, Skinport, and more (v4 API with v3 fallback). * Price history (get_price_history): Historical price data for a specific item on a given marketplace over a configurable number of days. * Portfolio analysis (analyze_portfolio): Structured breakdown by category (skins, containers, gloves, agents, charms, stickers) with subtotals, percentages, top N holdings, and unpriceable item count. * Write operations: Create, update, and delete portfolios, manage transactions, and configure price alerts. * Raw API access: Direct access to Pricempire's v3, v4, and v4.trader endpoints for advanced use cases. * Multi-portfolio support: Optionally scope queries to a specific named portfolio.

Which integrations are available for this server?

Provides tools to query and analyze a Counter-Strike 2 trader portfolio, including total value, category breakdowns, top holdings, and price comparisons across marketplaces. Allows price comparison and historical price data for in-game items from the Steam marketplace.

How do I use pricempire-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pricempire-mcp What's my portfolio worth right now?" 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.

pricempire-mcp

by nt4f04uNd

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Pricempire MCP Server

A Model Context Protocol (MCP) server for querying your Pricempire CS2 (Counter-Strike 2) trader portfolio: total value, breakdowns by category, top holdings, cross-marketplace price comparison, and price history.

Built on nt4f04uNd/pricempire, a fork of the official @pricempire/api Node.js client that adds support for the real Trader Portfolio API (/v4/trader/*), which the published npm package does not implement.

This server is on-demand: it can both inspect Pricempire data and, for the Trader API surface exposed by the installed JS client fork, perform write operations such as creating portfolios, managing transactions, and maintaining price alerts. It does not run alerts, bots, or schedulers by itself.

What it is useful for

This MCP server is useful when you want an LLM agent to help you inspect your Pricempire portfolio without manually clicking around the UI or exporting data.

Typical use cases:

check your total portfolio value, invested amount, unrealized P/L, and ROI
see your most valuable items and how concentrated your portfolio is
break down value by category such as skins, containers, agents, gloves, and charms
compare item prices across marketplaces
inspect historical price data for a specific item or marketplace source
create/update/delete trader portfolios and transactions
create/update/delete price alerts
access trader insights, trends, and raw v3/v4 endpoints
build portfolio summaries or visualizations in a separate skill layer

Related MCP server: Questrade MCP Server

Trader transaction notes

The live Pricempire Trader API has two quirks that matter for transaction writes:

asset_id alone is not reliable for item-specific transactions. For accurate imports, prefer passing asset_item_id as well.
transaction prices are effectively expected in cents, not floating-point USD values. For example, 0.70 USD should be sent as 70.

Because of that, trader_add_transaction in this MCP server behaves defensively:

if you provide asset_item_id, it creates the transaction and immediately rebinds it to the concrete item with a follow-up update
if you omit asset_item_id and provide a single market_hash_name, it returns a ready-to-open pricempire.com/api-data/... lookup URL
if you omit asset_item_id and provide multiple market_hash_names, it returns a one-shot browser-console script that resolves all required IDs in one run

How to start using it

The normal flow is:

Build this repository and configure your Pricempire API key.
Register the server in your MCP client.
Ask your agent questions about your portfolio.

Examples of the kinds of prompts this enables:

"What's my portfolio worth right now?"
"Show me my top 10 most valuable items."
"How much of my portfolio is in cases versus skins?"
"Which items have the biggest unrealized losses?"
"Visualize my portfolio by category."

Visualization skills

If you want a higher-level presentation layer on top of this MCP server, see pricempire-mcp-cs-tools.

That repository contains CS2-specific skills, prompts, and example visualizations built on top of the tools exposed here. The intended split is:

pricempire-mcp: data access and portfolio analysis tools
pricempire-mcp-cs-tools: visualization-oriented skill layer

Prerequisites

Node.js 18 or newer
A Pricempire API key with Trader tier access (portfolio value/holdings are a Trader-tier feature; see pricempire.com account settings). Cross-marketplace price lookup tools (get_item_prices, get_price_history) additionally require v3/v4 market data access depending on your plan.

Setup

npm install
cp .env.example .env
# edit .env and set PRICEMPIRE_API_KEY (and optionally DEFAULT_CURRENCY / DEFAULT_SOURCES)
npm run build

.env is git-ignored — never commit real API keys. .env.example documents each variable with placeholder values only.

Environment variables

Variable	Required	Description
`PRICEMPIRE_API_KEY`	Yes	Your Pricempire API key (UUID v4).
`DEFAULT_CURRENCY`	No	Default currency code (e.g. `USD`, `EUR`). Defaults to `USD`.
`DEFAULT_SOURCES`	No	Comma-separated default marketplace sources (e.g. `buff163,steam`) for `get_item_prices`. Defaults to `buff163,steam`.

Portfolios themselves aren't selected via env vars — the account tied to PRICEMPIRE_API_KEY may have multiple named portfolios (e.g. "Main portfolio", "Secondary portfolio"); tools default to all of them combined, or accept an optional portfolio name/slug filter per call.

Running

npm run dev     # run directly from TypeScript source with tsx (auto-reload)
npm run build   # compile to dist/
npm start       # run the compiled server (node dist/index.js)

The server communicates over stdio, per the MCP stdio transport convention.

Registering with an MCP client

Add an entry pointing at the built dist/index.js. Example mcp.json-style configuration:

{
  "mcpServers": {
    "pricempire": {
      "command": "node",
      "args": ["/absolute/path/to/pricempire-mcp/dist/index.js"],
      "env": {
        "PRICEMPIRE_API_KEY": "your-pricempire-api-key",
        "DEFAULT_CURRENCY": "USD",
        "DEFAULT_SOURCES": "buff163,steam"
      }
    }
  }
}

Adjust the path and the exact config file/format for your MCP client (e.g. Copilot CLI, Claude Desktop, etc.).

Quick start checklist

Copy .env.example to .env.
Set PRICEMPIRE_API_KEY.
Run npm install.
Run npm run build.
Register dist/index.js in your MCP client.
Restart or reload the MCP client if needed.
Ask a portfolio question such as "Analyze my portfolio."

Available tools

Tool family	Description
`get_portfolio_value`, `list_portfolio_items`, `get_item_prices`, `get_price_history`, `analyze_portfolio`	Opinionated high-level tools for portfolio analysis and visualization workflows.
`v3_*`	Raw parity tools for the JS client's `v3` methods: all items, basic/advanced data, inventories, structured items, item IDs, and self inventory.
`v4_*`	Raw parity tools for the JS client's paid-tier `v4` methods: prices, item metas, item catalog, and item images.
`trader_*`	Raw parity tools for the JS client's `v4.trader` methods: portfolios, transactions, alerts, insights, trends, signals, exports, and trader-tier prices.

Every tool catches API errors (invalid/missing key, rate limiting, plan restrictions, server errors) and returns a structured error object ({ error: true, kind, message, detail }) instead of throwing, so a calling agent can explain the problem in plain language.

`trader_add_transaction` expectations

For reliable use of trader_add_transaction, pass:

price in cents, for example 70 for 0.70 USD
asset_item_id whenever you already know the exact item variant

If asset_item_id is missing, the tool returns a structured helper payload instead of silently creating a likely mis-bound transaction.

Companion Copilot skill

See skills/pricempire-portfolio/SKILL.md for guidance an LLM agent can use to combine these tools when answering common portfolio questions.

Notes & limitations

Portfolio tools (get_portfolio_value, list_portfolio_items, analyze_portfolio) use the Pricempire Trader API (/v4/trader/portfolios*), via the nt4f04uNd/pricempire fork depended on in package.json ("@pricempire/api": "github:nt4f04uNd/pricempire#codex/trader-portfolio-api"). The published npm package does not implement these endpoints — see that fork's README for details on what was added.
The MCP server also exposes raw-parity tools for the installed fork's v3, v4, and v4.trader method surface in addition to the higher-level analysis helpers documented above.
This is currently built on a fork because upstream @pricempire/api does not yet expose the Trader Portfolio API. Upstream tracking issue: pricempire/pricempire#3.
get_item_prices and get_price_history use the market-wide v3/v4 endpoints from the original package and require separate plan access from the Trader tier; if your key doesn't have that access, these tools return a structured auth/forbidden error rather than crashing.

Available Tools

5 tools

analyze_portfolioAnalyze portfolioA

Fetch your Pricempire trader portfolio(s) once and return a structured analysis: total value, invested amount, profit/loss and ROI, a breakdown by item category (skin/container/glove/agent/charm/sticker) with subtotals and percentages, the top N most valuable holdings, and how many items had no current price match. Output is structured JSON, not prose, so the calling agent can turn it into a narrative for the user.

ParametersJSON Schema

Name	Required	Description	Default
`topN`	No	Number of top items to include. Defaults to 10.
`portfolio`	No	Name or slug of a specific Pricempire trader portfolio to use, for accounts with multiple portfolios (e.g. "Main portfolio"). Omit to use all portfolios on the account combined.

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It states the tool fetches data (read-only behavior) and returns structured JSON, and mentions handling of items without price matches. However, it does not disclose authentication needs, rate limits, or error behavior (e.g., empty portfolio), leaving some 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 is a single sentence but is well-structured and front-loaded with the core action. Every clause adds meaningful detail about output contents. There is no redundancy or filler.

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 low parameter complexity and absence of output schema, the description effectively explains all major output components (value, breakdown, top items, unmatched price count). It also notes the output format. Minor omission: handling of empty portfolios or errors, but overall complete enough for an analysis tool.

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?

The schema covers both parameters with descriptions (100% coverage), so baseline is 3. The description adds context: the 'portfolio' parameter is explained in terms of account setup (multiple portfolios), and omitting it means combining all. This clarifies usage beyond schema defaults.

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 'Fetch' and the resource 'portfolio analysis', listing specific outputs like total value, profit/loss, category breakdown, and top N holdings. This differentiates it from siblings such as list_portfolio_items (which likely lists items without analysis) and get_portfolio_value (which may just give a single value).

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 implies when to use this tool (when a comprehensive analysis with breakdowns is needed) and hints at alternatives (e.g., get_portfolio_value for just total value), but does not explicitly state when not to use it or list alternatives. However, the context is clear enough for an agent to infer.

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

get_item_pricesGet item prices across marketplacesA

Get current prices for one or more CS2 items (by market_hash_name) across marketplaces. Tries the Pricempire v4 API first (paid tier, richer per-source pricing); if that endpoint is unavailable (e.g. plan restriction) it falls back to the free v3 getAllItems endpoint. The response indicates which API tier was used, or reports the failure clearly.

ParametersJSON Schema

Name	Required	Description
`sources`	No	Marketplace source keys to price against (e.g. "buff163", "steam", "csfloat", "skinport"). Defaults to the server-configured DEFAULT_SOURCES.
`currency`	No	Currency code (e.g. "USD", "EUR"). Defaults to the server-configured DEFAULT_CURRENCY.
`market_hash_names`	Yes	One or more exact item market_hash_name values to look up, e.g. "AK-47 \| Redline (Field-Tested)".

TDQS

A4/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 the dual-API fallback strategy and that the response indicates which tier was used, adding useful behavioral context.

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 highly concise—two sentences packing purpose, behavior, and fallback. Every sentence adds value with no redundancy.

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 or annotations, the description adequately covers purpose, fallback, and error reporting. It lacks details on rate limits or authentication, but is sufficient for a basic price lookup 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 description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema, as it repeats the parameter intent without additional details.

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 'get' and the resource 'prices for one or more CS2 items across marketplaces'. It distinguishes from sibling tools like analyze_portfolio and get_price_history, which address different operations.

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 mentions a fallback mechanism between paid and free API tiers, but does not explicitly state when to use this tool versus alternatives. The usage context is implied but not fully defined.

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

get_portfolio_valueGet portfolio valueA

Get the total current value of your Pricempire trader portfolio(s): value, 24h change, item count, total invested, profit/loss, and ROI, per portfolio and combined. Uses the Pricempire Trader API (v4/trader/portfolios), tied to the account owning the configured API key. Requires a Pricempire trader-tier subscription.

ParametersJSON Schema

Name	Required	Description	Default
`portfolio`	No	Name or slug of a specific Pricempire trader portfolio to use, for accounts with multiple portfolios (e.g. "Main portfolio"). Omit to use all portfolios on the account combined.

TDQS

A4.3/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It reveals the underlying API endpoint and subscription requirement but does not explicitly state read-only or non-destructive nature. Adequate but not fully transparent.

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 redundancy. Front-loaded with all key information: purpose, metrics, backend, and requirement. 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?

Despite no output schema, the description explicitly lists all returned metrics (value, 24h change, item count, etc.) and explains per-portfolio and combined aggregation, making the return format clear.

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?

Only one optional parameter with schema description. Tool description adds example ('Main portfolio') and clarifies behavior when omitted, enhancing understanding 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?

The description clearly states the tool returns total portfolio value including specific metrics (value, 24h change, item count, etc.) and distinguishes from siblings by focusing on aggregated value rather than individual items or price history.

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?

Provides clear context: when to use (get total value) and prerequisites (API key, trader-tier subscription). However, it does not explicitly state when not to use or suggest alternatives among siblings.

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

get_price_historyGet item price historyA

Get historical price data for a given marketplace source over a number of days (Pricempire v3 getPriceHistories). Useful for "show me price history for X" style questions about market trends.

ParametersJSON Schema

Name	Required	Description
`days`	No	Number of days of history to return. Defaults to 30.
`appId`	No	Steam app ID. Defaults to 730 (CS2).
`source`	No	Marketplace source key, e.g. "buff163", "steam", "csfloat". Defaults to "buff163".
`currency`	No	Currency code (e.g. "USD", "EUR"). Defaults to the server-configured DEFAULT_CURRENCY.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description is the sole source for behavioral traits. It discloses the tool's read-only nature (historical price data) and scoping (days, source). However, it omits details like output format, pagination, or limitations (e.g., max days), leaving some uncertainty for an agent.

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 brief and front-loaded with the essential action. The parenthetical mention of the API endpoint is somewhat extraneous but not overly distracting. It efficiently conveys the core purpose in two sentences.

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

Completeness3/5

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

Given no output schema and no annotations, the description fails to explain what the tool returns (e.g., structure of price data). While the tool's purpose is clear, an agent would lack details about the response format. For a simple data retrieval tool, this is a moderate gap.

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 the baseline is 3. The description does not add any extra meaning beyond what the schema already provides for parameters like 'days', 'source', etc. It merely echoes the purpose of the parameters in a general way.

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 explicitly states 'Get historical price data for a given marketplace source over a number of days,' which is a specific verb-resource pair. The added context about Pricempire v3 and the example use case ('show me price history for X') further clarify the scope and distinguish it from sibling tools like get_item_prices.

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 provides a clear usage context: 'Useful for...show me price history for X style questions.' This implicitly guides the agent on when to invoke this tool. However, it does not explicitly contrast with alternatives or specify when not to use it, missing an opportunity for clearer differentiation.

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

list_portfolio_itemsList portfolio itemsA

List the items held in your Pricempire trader portfolio(s), with per-item details (current price, holdings/quantity, float, paint seed, stickers, category, avg buy price, unrealized P/L, ROI), sorted by current value descending. Supports optional limit and min_value filters, and an optional portfolio name/slug filter for accounts with multiple portfolios. Useful for "what are my most valuable items" style questions.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of items to return.
`min_value`	No	Only include items whose current value is >= this amount.
`portfolio`	No	Name or slug of a specific Pricempire trader portfolio to use, for accounts with multiple portfolios (e.g. "Main portfolio"). Omit to use all portfolios on the account combined.

TDQS

A4.2/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 the full burden. It discloses the output fields and sorting behavior but does not mention whether the operation is read-only, potential rate limits, or authentication requirements. The description is adequate but lacks some contextual details beyond what is implicit.

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 unnecessary words. The first sentence states the core purpose and output fields, the second mentions optional filters and a typical use case. Information density is high.

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 3 optional parameters and no output schema, the description provides a solid overview of the return value including key fields like price, quantity, float, etc. It covers the sorting and filter options well. It could mention pagination if limit is used, but overall it's sufficient for an agent to understand the tool's behavior.

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 descriptions for each parameter. The description adds value by summarizing the filter options (limit, min_value, portfolio name/slug) and explaining the portfolio parameter's behavior for multi-portfolio accounts, which enhances understanding beyond the raw 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?

Clearly states it lists items from Pricempire trader portfolios with detailed fields and sorting. The verb 'list' and resource 'portfolio items' are specific, and the tool is distinct from siblings like analyze_portfolio (analysis) and get_portfolio_value (aggregate value).

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 the use case as 'what are my most valuable items' style questions, which gives clear context. However, it does not explicitly state when not to use it or mention alternatives among siblings, though the purpose is self-explanatory given the sibling names.

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.

5 tool updatesv0.1.0Jul 9, 2026
- First observedanalyze_portfolio
- First observedget_item_prices
- First observedget_portfolio_value
- First observedget_price_history
- First observedlist_portfolio_items

Install Server

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

TDQS

A4.2/5.0

Scored 2026-07-09 02:35 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: full portfolio analysis, item prices, portfolio value, price history, and portfolio item listing. There is no overlap in their purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_portfolio, get_item_prices), making it predictable and easy to understand.

Tool Count5/5

With 5 tools, the server covers the core functionalities (pricing, portfolio value, history, listing, analysis) without being over- or under-scoped.

Completeness4/5

The tool set provides essential read operations for CS2 item pricing and portfolio management. Minor gaps exist, such as no global item search or filter, but the analysis tool compensates by summarizing top holdings.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Crypto Prices Mcp
io.github.varvararatta
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Cryptocurrency Finance
2
Pinchwork MCP Server
io.github.pinchwork
MCP server for Pinchwork - an agent-to-agent task marketplace with credits-based economy
Agent Orchestration Autonomous Agents Finance
23
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
H-Index A
ai.xr-utilities
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Search Documentation Access
2

Related MCP Servers

MCP Server for stock and
Cryptocurrency Finance Web Scraping
aahl
A
license
A
quality
C
maintenance
📈 提供股票、加密货币的数据查询和分析功能MCP服务器
Updated 6 months ago (2026-03-26 03:14 UTC)
18
392
MIT
Questrade MCP Server
Finance Search Data Platforms
zachmelin
A
license
B
quality
C
maintenance
An unofficial MCP server that integrates with the Questrade API to provide access to trading accounts, market data, and portfolio information. It enables users to view balances, track positions, search symbols, and analyze market trends through natural language.
Updated 3 months ago (2026-06-10 19:51 UTC)
9
15
6
MIT
mcp-server-runescape
Games & Gamification Open Data
stjepko-xyz
A
license
A
quality
D
maintenance
MCP server for interacting with RuneScape and Old School RuneScape data, including item prices, player hiscores, and more.
Updated 6 months ago (2026-02-26 23:25 UTC)
6
12
13
Apache 2.0
ibkr-mcp
Finance Research & Data
jeffbai996
F
license
Not graded
quality
B
maintenance
An MCP server that turns Interactive Brokers into a question-answering portfolio analyst.
Updated 6 days ago (2026-09-05 05:02 UTC)
4
-

Pricempire MCP Server

What it is useful for

Trader transaction notes

How to start using it

Visualization skills

Prerequisites

Setup

Environment variables

Running

Registering with an MCP client

Quick start checklist

Available tools

trader_add_transaction expectations

Companion Copilot skill

Notes & limitations

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

`trader_add_transaction` expectations