Uses public Binance P2P ad listings to provide a USDT/VES market reference rate (median of P2P ads, with SELL or BUY options), which can be used for conversions and calculating the gap against the official BCV rate.
Click on "Deploy 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., "@tasas-ve-mcp How much is $200 worth in bolívares today?"
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.
Venezuelan exchange rates for your AI assistant, in one line. Official BCV rate (USD, EUR) and the USDT P2P market reference, as an MCP server, a CLI and a Python library.
Example conversation (illustrative figures):
You: How much is 250 dollars in bolívares today? Claude: At today's BCV official rate (Bs 36.59 per USD, 2 Nov 2026), USD 250 = Bs 9,146.85. The USDT P2P reference is Bs 50.20, a 37 % gap.
Your assistant stops guessing. LLMs don't know today's rate; this gives it the real number with source and timestamp.
Fast and cheap. One small tool call, maths done locally — no long prompts, no scraping by the model, minimal tokens.
Keeps working when the source is down. The last known value is cached on disk and returned with a warning.
Related MCP server: Economía Venezuela MCP
Requires uv (or pip install git+https://github.com/abixaiprin/tasas-ve-mcp).
VS Code — .vscode/mcp.json
{ "servers": { "tasas-ve": { "command": "uvx", "args": ["--from", "git+https://github.com/abixaiprin/tasas-ve-mcp", "tasas-ve-mcp"] } } }Claude Desktop / Cursor — MCP config
{ "mcpServers": { "tasas-ve": { "command": "uvx", "args": ["--from", "git+https://github.com/abixaiprin/tasas-ve-mcp", "tasas-ve-mcp"] } } }Terminal
uvx --from git+https://github.com/abixaiprin/tasas-ve-mcp tasas-ve # BCV + P2P rates
uvx --from git+https://github.com/abixaiprin/tasas-ve-mcp tasas-ve 100 USD VES
uvx --from git+https://github.com/abixaiprin/tasas-ve-mcp tasas-ve 5000 VES USD --p2pPython
from tasas_ve import Servicio
s = Servicio()
s.convertir(100, "USD", "VES") # {'resultado': 3658.74, 'tasa_usada': 36.5874, ...}Run it as a small web service and call it over HTTP. It also exposes remote MCP at /mcp.
uvx --from git+https://github.com/abixaiprin/tasas-ve-mcp tasas-ve-mcp --http --port 8000Endpoint | Example |
| BCV + P2P rates |
|
|
| health check |
React / Vue / any JS
const r = await fetch("https://YOUR-SERVICE/api/convertir?monto=100&de=USD&a=VES");
const { resultado, tasa_usada } = await r.json();Java
var res = HttpClient.newHttpClient().send(
HttpRequest.newBuilder(URI.create("https://YOUR-SERVICE/api/tasas")).build(),
HttpResponse.BodyHandlers.ofString());Deploy for free: the repo includes render.yaml — on Render choose New → Blueprint and pick this repo.
Tool | What it does |
| Official BCV rate: Bs per 1 USD and 1 EUR |
| USDT/VES market reference (median of P2P ads, |
| Converts between VES, USD, EUR and USDT using |
| Gap (%) between the official rate and the P2P reference |
One source of truth for the rate. Your apps, spreadsheets and AI assistants read the same number, with source and timestamp — no more copying it by hand every morning.
Plug it into what you already use: Claude, Cursor or VS Code via MCP; React, Vue, Java or PHP via the REST API.
Self-hosted and auditable. It's open source, it only reads public pages and it sends no data about your company.
Resilient. If the source goes down, your systems keep the last known value instead of breaking.
Tokens per question | one tool call + a ~200-byte JSON answer |
Cache | BCV 30 min · P2P 3 min · last value saved to |
Network | Only public pages; nothing is sent about you |
flowchart LR
A[AI assistant] -->|MCP tool call| B[tasas-ve-mcp]
B --> C{Cache fresh?}
C -- yes --> A
C -- no --> D[BCV website / P2P ads]
D --> E[(Last known value)]
E --> ABCV: public website bcv.org.ve. If its TLS certificate can't be verified, the answer says so.
P2P: public Binance P2P ad listing. It is a market reference, not an official rate. Not affiliated with BCV or Binance.
Rates are informative. Check the official source before any legal or accounting use.
Rate history and daily average
More sources (other P2P platforms, parallel references)
REST API and a widget for websites
Other countries
Ideas? Open a discussion.
git clone https://github.com/abixaiprin/tasas-ve-mcp && cd tasas-ve-mcp
pip install -e ".[dev]" && pytestI adapt tools like this to your company: integrations with your systems, payment flows, AI assistants and support. → dev-abixai.netlify.app · dev.abixai.martinez@gmail.com
If this saved you time:
⭐ Star the repo — it helps other developers find it.
☕ Buy me a coffee on Ko-fi — keeps new tools coming.
🔁 Share it with a team that still copies the rate by hand.
MIT © 2026 Abixai Prin. You can use, modify and share it; keep the copyright notice.
Diferencia porcentual entre la tasa oficial BCV del dólar y la referencia USDT P2P.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden, yet it discloses nothing about sign convention, units, data freshness, or whether a failure in either underlying source degrades the result. For a computed/derived endpoint with zero annotation coverage this is a meaningful gap.
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?
A single well-formed sentence with no filler, and the defining concept (percentage difference between the two named rates) is front-loaded. Nothing is wasted.
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?
With no output schema, no annotations, and no parameters, the description is the only documentation and it omits the return shape (a bare percentage, a signed number, an object with both rates). It identifies the metric but does not fully equip an agent to interpret the response.
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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The description correctly implies the call needs no arguments.
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?
Names a specific derived metric (percentage gap between the official BCV dollar rate and the USDT P2P reference), which is clear enough that an agent can tell it apart from tasa_bcv and tasa_p2p, which supply the individual rates. It does not explicitly state the relationship to those siblings, so it falls short of full differentiation.
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 is purely definitional: it says what the metric is, never when to call it instead of tasa_bcv, tasa_p2p, or convertir. There is no explicit or even clearly implied routing guidance, leaving the agent to infer that this is the comparison tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convierte un monto entre VES, USD, EUR y USDT. fuente='bcv' (oficial) o 'p2p' (mercado).
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| de | Yes | ||
| monto | Yes | ||
| fuente | No | bcv |
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 never says whether the tool fetches live rates (network call) or computes from a cached rate, whether it is read-only/side-effect free, how fresh the rate is, or what happens with unsupported currency codes — significant gaps for an unannotated tool.
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 compact sentences with no filler, front-loaded with the core action and followed by the source qualifier. Slightly too terse given the ambiguity it leaves, but nothing is wasted.
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?
With no annotations, no output schema, and 0% schema description coverage across 4 parameters, the description should explain what the result looks like (converted amount? rate used?) and behavior on invalid currencies. It does neither, leaving the agent unable to fully predict the call.
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 0%, so the description must compensate. It usefully names the accepted currency set for 'de'/'a' (though not that they are the from/to direction) and documents 'fuente' with its two values and default 'bcv'. That is partial coverage; 'monto' is only implied and directionality of de/a is left ambiguous.
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?
States a specific verb ('Convierte') and resource ('un monto entre VES, USD, EUR y USDT'), so an agent knows this is a currency-conversion tool. It does not, however, distinguish itself from the siblings tasa_bcv/tasa_p2p/brecha_cambiaria, which also deal with rates but are not mentioned.
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 two fuente values ('bcv' oficial vs 'p2p' mercado) give a hint about which source variant to pick when converting. But there is no explicit when-to-use guidance versus the sibling rate tools, and no statement of prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tasa oficial del Banco Central de Venezuela: bolívares por 1 USD y por 1 EUR.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the source (BCV) and unit semantics, which is useful, but does not state freshness, authentication needs, whether it is read-only, or error behavior. For a zero-parameter rate lookup this is minimally adequate but has clear gaps.
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?
A single, front-loaded sentence that states the source, resource, and unit of return. Every element earns its place with no 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 zero-parameter rate-fetching tool with no output schema, the description sufficiently explains what is returned: official BCV rates in bolívares per USD and EUR. It could add freshness or usage context, but the core call semantics are complete.
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 tool has zero parameters, so the baseline is 4. The description appropriately does not invent parameter details, and the USD/EUR mention clarifies the implicit scope of the lookup.
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 identifies the resource as the official BCV exchange rate and specifies the output units: bolívares per 1 USD and per 1 EUR. It distinguishes itself from tasa_p2p by emphasizing 'oficial' and 'Banco Central de Venezuela', though it does not explicitly name or route against siblings.
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?
There is no explicit guidance on when to use this tool versus tasa_p2p, convertir, or brecha_cambiaria. The official-source framing implies a use case, but the definition leaves the agent to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Referencia de mercado USDT/VES: mediana de anuncios P2P. lado='SELL' (venta) o 'BUY' (compra). No es oficial.
| Name | Required | Description | Default |
|---|---|---|---|
| lado | No | SELL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does carry the provenance burden and does well on it: it discloses the data source (median of P2P ads) and its non-official reliability caveat. It says nothing about freshness/snapshot timing, caching, or failure behavior when there are too few ads, which matters for a rate tool.
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 telegraphic sentences, front-loaded with the resource and computation, followed by the parameter values and the non-official caveat. Nothing is wasted, though the clipped style borders on underspecification.
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?
One optional parameter and no output schema or annotations, so the description is nearly sufficient, but it never indicates what is returned (a single rate value? a timestamp? ad counts?) or how stale the median may be — both relevant for a market-rate lookup.
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 0% and there is no enum, so the description must carry the parameter — it does explain lado='SELL' (venta) vs 'BUY' (compra). However, it does not resolve the key ambiguity of whether SELL means the rate obtained when selling USDT or the side of the ad book being read.
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?
States a specific resource and computation: a USDT/VES market reference derived from the median of P2P listings. The closing 'No es oficial' implicitly contrasts it with the official-rate sibling (tasa_bcv), but the differentiation is only implied rather than naming the sibling.
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 tells the agent what the value represents and flags that it is non-official, which hints at when to prefer it over an official rate, but it never explicitly says when to use this versus tasa_bcv, convertir, or brecha_cambiaria.
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.
v0.1.0brecha_cambiariaconvertirtasa_bcvtasa_p2pScored across 4 tools
Each tool targets a distinct concept: official BCV rate, P2P market reference, amount conversion, and the percentage gap between them. The `convertir` tool's `fuente` parameter could superficially be confused with `tasa_bcv`/`tasa_p2p`, but the descriptions make clear it performs conversion rather than rate lookup. No two tools do the same thing.
All names are lowercase snake_case, which is consistent, but the grammatical style is mixed: `tasa_bcv`/`tasa_p2p` are noun phrases, `convertir` is a bare verb, and `brecha_cambiaria` is another noun phrase. It reads fine in Spanish and each name is still self-explanatory, so this is a minor deviation rather than a real inconsistency.
Four tools is a tight, well-scoped surface for a narrow domain (Venezuelan exchange rates). Every tool earns its place: two rate sources, one conversion utility, one derived metric, with no redundant or filler entries.
The surface covers the core lifecycle: fetch official rate, fetch market rate, convert between all four currencies, and compute the gap. The main gap is historical/time-series data (no date parameter), so an agent cannot retrieve past rates, but all current-state workflows are covered.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Loan & mortgage calculator, compound interest, ROI, crypto prices, FX conversion for AI agents.
Live and historical FX rates (ECB via Frankfurter) — paid per call (x402/credits), 2 tools
