refinex-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REFINEX_API_KEY | No | Your RefineX API key. Required for authenticated tools (list_signals, get_signal_for_instance, get_signals_summary). Tools get_live_signal and get_suppression_log work without it. | |
| REFINEX_API_BASE_URL | No | Override the base URL for self-hosted API. | https://refinex-api.onrender.com |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_live_signalA | Get the single best active AWS spot arbitrage signal right now. No API key required. Returns the highest-confidence active signal including:
If no signal clears the confidence threshold, returns action="use_on_demand" with a rationale. suppressed_last_6h will still be populated. This is the fastest way to get real AWS spot data — zero credentials needed. |
| get_suppression_logA | Get the RefineX suppression log — a mix of delivered and suppressed signals. Shows what RefineX fired vs. what it held back and why. No API key required. Args: limit: Number of signals to return (1–20, default 20) Returns:
Suppression reasons: "confidence_below_threshold", "stale_data", "ttl_expired". A high suppression rate is intentional — discipline is the product. |
| get_healthA | Get RefineX API health and last AWS data ingestion timestamp. No API key required. Returns:
Use this to verify real-time data is flowing before making infrastructure decisions. If aws.status is "degraded", last_ingestion is >10 minutes old. |
| list_signalsA | List active spot arbitrage signals with optional filters. Requires REFINEX_API_KEY env var. Args: cloud: Cloud provider — "aws", "gcp", or "azure" (default: "aws") region: Filter by region, e.g. "us-east-1", "us-west-2" (optional) instance_type: Filter by EC2 type, e.g. "m6i.large", "c7g.xlarge" (optional) confidence_min: Minimum confidence score 0.0–1.0 (default: 0.0) page: Page number (default: 1) limit: Results per page, max 500 (default: 50) Returns:
|
| get_signal_for_instanceA | Get the single best spot action for a specific cloud/region/instance type. Optimized for autoscalers that need one clear, deterministic action. Requires REFINEX_API_KEY env var. Args: cloud: Cloud provider — "aws", "gcp", or "azure" region: AWS region, e.g. "us-east-1", "us-west-2", "eu-west-1" instance_type: EC2 instance type, e.g. "m6i.large", "c7g.xlarge", "t3.medium" fallback: What to return when no signal exists — "on_demand" (default), "wait", or "none" Returns:
Use fallback="on_demand" in CI/CD pipelines so you always get a safe default. Use fallback="wait" in cost-sensitive batch jobs. |
| get_signals_summaryA | Get aggregate summary of current AWS spot opportunities. Requires REFINEX_API_KEY env var. Args: cloud: Filter by cloud provider (optional) region: Filter by region (optional) min_savings: Minimum savings % to include in summary (default: 50.0) confidence_min: Minimum confidence score (default: 0.80) Returns:
Use this for dashboards or periodic CI checks: "How many high-confidence deals exist right now, and in which regions?" |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose: health check, best signal, per-instance signal, aggregate summary, suppression log, and paginated list. No overlap in functionality.
All tool names follow a consistent verb_noun pattern using snake_case, e.g., get_health, get_live_signal, list_signals. No deviations.
With 6 tools, the set is well-scoped for a focused API providing spot arbitrage signals. Each tool earns its place without being excessive or insufficient.
The tool surface covers health, best signal, per-instance queries, summaries, suppression logs, and listing. A minor gap is the lack of a direct 'get_signal_by_id' endpoint, but list_signals with filtering can serve that purpose.