Goldsky MCP for AI. Manage Web3 data pipelines from your chat.
Works with every AI agent you already use
…and any MCP-compatible client








How this MCP server connects to your AI agent
Goldsky (Web3 Data Indexing & Subgraphs) MCP lets you control complex blockchain data pipelines from your chat window. You can list, create, pause, and monitor real-time indexing jobs for Web3 data streams using natural language commands.
What AI agents can do with Goldsky (Web3 Data Indexing & Subgraphs) Automation
Create pipeline
Builds and activates a brand new data indexing pipeline in the project.
Delete pipeline
Permanently removes an existing, obsolete pipeline definition from your account.
Get pipeline error count
Calculates the number of errors that occurred in a specified time frame for a pipeline.
Get the current operational state of any indexed pipeline—whether it's running, paused, or has failed.
Stop a runaway pipeline using pause_pipeline, restart one with restart_pipeline, or resume work when ready.
Run validate_pipeline to check your source, transformation, and sink definitions for errors before deploying anything.
See all existing pipelines or fetch specific metadata about a single job using list_pipelines and get_pipeline.
Pull historical execution logs with get_pipeline_logs, or quantify failures in a time window via get_pipeline_error_count.
Ask an AI about this
Waiting for input…
What AI agents can do with Goldsky (Web3 Data Indexing & Subgraphs) MCP - 12 Tools
These twelve tools let you manage every aspect of data indexing: from listing active pipelines and checking statuses to creating new jobs or deleting old ones.
Make your AI actually useful.
Add this MCP to Claude, Cursor, or Windsurf and your AI stops guessing. It gets real tools to look things up, take action, and handle the stuff you keep doing by hand.
Start using Goldsky (Web3 Data Indexing & Subgraphs) on VinkiusCreate Pipeline
Builds and activates a brand new data indexing pipeline in the project.
Delete Pipeline
Permanently removes an existing, obsolete pipeline definition from your account.
Get Pipeline Error Count
Calculates the number of errors that occurred in a specified time frame for a...
Get Pipeline Logs
Pulls detailed historical records and debug messages from a running or failed...
Get Pipeline State
Checks the internal, granular status of a pipeline's execution state.
Get Pipeline Status
Provides the current operational runtime status (running, paused, failed) for an indexed job.
Get Pipeline
Retrieves detailed metadata for one specific data indexing job.
List Pipelines
Returns a list of every pipeline currently defined within your project.
Pause Pipeline
Temporarily halts the execution of an active data indexing stream.
Restart Pipeline
Forces a full restart of an existing pipeline job.
Resume Pipeline
Reactivates a pipeline that was previously paused.
Validate Pipeline
Checks the structure and definitions of a pipeline to ensure it's ready for deployment.
Security and governance baked right in.
Pick your AI client below to get set up. Just create a Vinkius account, subscribe, and you're instantly up and running. We handle the entire backend infrastructure, delivering out-of-the-box support for HTTPS Streamable, SSE, and OAuth2—zero messy routing required.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with Goldsky (Web3 Data Indexing & Subgraphs), then connect any of our 5,100+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 5,100+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by Goldsky. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Built on the Model Context Protocol (MCP) for Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This connection provides 12 powerful capabilities that interface natively with Claude, ChatGPT, Cursor, and other compatible AI platforms. No middleware. No custom integration required.
Debugging cross-chain data feeds feels like a scavenger hunt.
Today, if your Web3 data pipeline breaks, you're bouncing between the platform UI, the logging console, and multiple dashboard views. You copy error messages into Slack, wait for someone to manually check the status, and then hope they can pinpoint which specific block or source caused the failure.
With this MCP, that manual process disappears. Your agent handles the investigation flow. Need to see what broke? Just ask it to pull the execution logs using get_pipeline_logs. It pulls the context you need instantly.
Control and visibility via Goldsky (Web3 Data Indexing & Subgraphs) MCP
You no longer have to manually cycle through 'Start', 'Pause', and 'Restart' buttons in the console. You tell your agent, 'Pause this job,' or 'Resume that one.' The system handles the state change.
The difference is control. This MCP lets you treat your data infrastructure like code—you manage it with commands: pause_pipeline, resume_pipeline, and restart_pipeline are all available through plain conversation.
What your AI can actually do with this
Managing Web3 data is messy work. It involves building and maintaining pipelines that read raw blockchain feeds and turn them into usable records. This MCP gives you direct control over those Goldsky Turbo pipelines right from your agent interface. You can list every active pipeline, check its current status, or pull detailed execution logs to troubleshoot an issue immediately.
If a pipeline hits a snag, you don't have to jump into the web console; you just tell your AI client to validate the definition first, then pause it if needed. This is about making sure your data infrastructure stays alive and accurate without leaving your code editor. It’s built for people who need reliable, real-time visibility on complex cross-chain data flow.
019e5d21-0e7d-726c-ab60-b42f12aebdff Here's how it actually works
The bottom line is you manage complex Web3 data infrastructure using simple conversation, not complicated UI clicks.
Subscribe to the MCP and enter your Goldsky API Key.
Tell your agent what you need done—for instance, 'List all my active pipelines' or 'Pause the swaps monitor.'
The system executes the necessary tool calls (like list_pipelines or pause_pipeline) and returns a clean status update directly to your chat.
Who is this actually for?
This MCP is for the data engineer who gets tired of logging into three different dashboards just to check if a pipeline broke. It’s also for the protocol developer needing instant visibility on cross-chain indexing failures.
Uses get_pipeline_logs and get_pipeline_error_count to diagnose why data flow stopped, pulling specific error metrics without leaving their terminal.
Manages the entire lifecycle—running validate_pipeline before deploying a new subgraph or calling create_pipeline on demand.
Handles resource management by using pause_pipeline and resume_pipeline to throttle services during maintenance windows.
What Changes When You Connect
Instant visibility into indexing failures. You can check the current run status and error count with get_pipeline_status and get_pipeline_error_count, letting you know if something broke without digging through console logs.
Full lifecycle control over data streams. Need to update the source? Use pause_pipeline first. When you're done, call resume_pipeline to minimize downtime.
Risk-free deployment workflow. Before running create_pipeline, always use validate_pipeline. This catches bad configurations (sources or sinks) early, preventing costly runtime failures.
Deep troubleshooting access. If the data is wrong, you need context. Use get_pipeline_logs to pull specific execution records and find out exactly which block failed.
Simple project overview. list_pipelines gives you a quick inventory of every job running, so you always know what's active in your cross-chain monitoring setup.
See it in action
Debugging a broken data feed
The team noticed the NFT event pipeline stopped suddenly. Instead of SSHing into a server, they asked their agent to run get_pipeline_status and then use get_pipeline_logs for that specific job. They found an API key mismatch in the logs and fixed it immediately.
Preparing for maintenance
The ops team needs to update the core data source schema. To prevent corrupted reads, they ran validate_pipeline first. Once validated, they used pause_pipeline before making changes, ensuring zero downtime risk.
Auditing historical failures
A client questioned missing swap records. The developer used get_pipeline_error_count for the last 24 hours on the swaps pipeline to prove that while errors occurred, they were isolated and handled by retries.
Building a new monitor
A product team wants to track a brand new asset type. They used list_pipelines to see what already existed, then called create_pipeline with the new JSON definition, monitoring it via get_pipeline state.
The honest tradeoffs
Running restarts blindly
When a pipeline fails, many people immediately call restart_pipeline. This often just masks the underlying structural error and leads to repeated failure cycles.
Don't just restart it. First, use validate_pipeline to check the definition structure. If that passes, then try restarting. Better yet, pause_pipeline, fix the source code, and resume_pipeline.
Assuming all data is clean
A developer runs a new pipeline using create_pipeline without checking the definitions first. The job starts but immediately fails because of an incompatible sink definition.
Always validate definitions upfront. Before calling create_pipeline, run validate_pipeline to ensure your sources and sinks match up perfectly.
Overlooking resource usage
A runaway pipeline consumes all resources overnight. The team only checks the status, but can't stop it in time.
If you suspect a job is consuming too much, use pause_pipeline immediately to halt execution before calling get_pipeline_logs for investigation.
When It Fits, When It Doesn't
Use this MCP if your primary pain point involves managing the full lifecycle of complex, real-time Web3 data feeds. You need granular control: you must be able to check state (get_pipeline_status), audit definitions (validate_pipeline), and retrieve historical context (get_pipeline_logs). Don't use it if you just need a simple list of services; then, list_pipelines is enough. If your only goal is to know 'is it running?', get_pipeline_status is sufficient. But for actual data reliability and operational safety, you need the full suite: always audit with validate_pipeline before creating or restarting.
Questions you might have
How do I check if a pipeline is healthy using get_pipeline_error_count? +
get_pipeline_error_count lets you query the number of errors within a specific time window. This gives you quantitative proof of data integrity, which is better than just seeing 'running' status.
Can I use validate_pipeline to check my entire project? +
No, validate_pipeline checks the definition of one specific pipeline at a time. You must first use list_pipelines to identify all jobs and then run validation on each one before deployment.
What's the difference between get_pipeline_status and get_pipeline_state? +
get_pipeline_status gives you the high-level operational status (running, paused). get_pipeline_state provides deeper internal metrics about how the pipeline is managing its own resources.
How do I delete a pipeline using delete_pipeline? +
Calling delete_pipeline removes the job permanently and irreversibly. Always ensure you have backed up any necessary definitions or logs before running this tool.
What's the best way to manage resources using `pause_pipeline` and `resume_pipeline`? +
Using pause/resume is ideal for cost control. Pausing a pipeline stops all resource usage instantly, perfect for maintenance or downtime. You can later restart it with resume_pipeline without losing its definition.
How do I use `get_pipeline` to view the full schema and configuration of an existing workflow? +
The get_pipeline tool returns the complete definition, including all sources, transforms, and sinks. This lets you confirm exactly how data is configured to flow before making changes or debugging.
If I don't know which pipelines exist, how do I find them using `list_pipelines`? +
list_pipelines retrieves an overview of every pipeline defined in your project. This list includes all pipelines, whether they are currently running, paused, or inactive.
What specific errors does `validate_pipeline` check before I deploy a new data flow? +
The validation tool checks the structural integrity of the pipeline definition. It ensures your sources, transforms, and sinks match expected schemas, preventing deployment failures due to bad configuration.
Can I check if my pipeline configuration is valid before deploying it? +
Yes! Use the validate_pipeline tool with your definition object. It will check your sources, transforms, and sinks for errors without actually starting a new pipeline.
How do I monitor errors in a running pipeline? +
You can use get_pipeline_error_count to see the number of issues in a time window, or get_pipeline_logs to fetch the actual execution logs for detailed debugging.
Is it possible to temporarily stop a pipeline without deleting it? +
Absolutely. Use the pause_pipeline tool to stop execution. When you are ready to start again, simply use the resume_pipeline tool.
We've already built the connector for Goldsky. Just plug in your AI agents and start using Vinkius.
No hosting. No infrastructure. No complex setup.
All 12 tools are live and waiting.
You're up and running in seconds.
Vinkius gives your AI agents access to the full catalog of app connectors, all fully managed, secure, and enterprise-ready. One subscription, every tool you need.
Built, hosted, and secured by Vinkius. You just connect and go.