Delivering Data & Services in the Age of AI Agents

• AI agents need tools to perform real-world tasks 

• Data and Service providers can deliver their products as tools for their customers’ AI agents to use 

• MCP is the fast-evolving standard for defining your tools’ capabilities and how agents can interact with them 

• MCP is described as a USB-C port for AI applications – it enables any compatible AI model to use any compatible tool 

• ipushpull is using MCP to enable agentic workflows in capital markets 

• Authentication, Access Control and Auditability remain critical for adoption 

At ipushpull, we make it possible for our customers to deliver data and workflows into the applications their clients are already using – applications like Excel and chat. The rise of autonomous AI agents adds both new opportunities and new challenges to doing this. 

AI agents are starting to gain acceptance even in the conservative world of capital markets. Market participants are excited because agents promise improvements in operational efficiency across the whole trading lifecycle. Traders and Portfolio Managers could use agents to monitor a broader set of news and information sources more quickly, tailor decisions and ideas to individual clients more precisely and improve overall execution quality. Always-on compliance agents could screen communications more thoroughly, and risk agents could detect and explain problems sooner. 

So how can data and service providers deliver their services into these new agentic workflows? 

Traditional Ways of Delivering Data & Services 

Historically, we have delivered capabilities through a range of familiar channels: 

• Excel add-ins - pushing data directly into users’ spreadsheets

• REST APIs - programmatic access for integration into in-house models and systems

• Chatbots - financial markets professionals live in chat - bots let them pull data and trigger workflows without context switching

• FDC3-based desktop interoperability - when workflow steps are split across siloed desktop apps (often from different providers), FDC3 enables the sharing of context between them to streamline disjointed, manual steps

If you would like to know more about traditional methods of delivering data, read this blog.

What Changes with AI Agents? 

In contrast to these user-driven workflows, AI agents can autonomously (or semi-autonomously) run workflows on a user’s behalf.  

At its core, an agent is an LLM-powered helper. After the end user gives it a natural language goal, it's up to the agent to decide the sequence of steps and the tools and data sources to use in order to achieve that goal without the user spelling out every command. 

One option for data and service providers to inject themselves into these new workflows is to deliver a fully-fledged agent - a topic we will cover in a subsequent blog post. An alternative is to provide MCP-enabled tools for a customer’s own agent to use. 

What Is a Tool and Why Do Agents Need Them? 

The LLMs at the heart of agents are highly capable at reasoning, analysis and generating text, but on their own, they cannot interact with external systems and are surprisingly weak at structured operations and even tasks like basic arithmetic. Tools close that gap. 

A tool is a well-defined external capability that an agent can choose to call as part of its plan to achieve the user’s goal. Typical tools might provide access to data, calculations or system actions. For example, suppose you want to build a basic agent with the goal of automatically notifying clients of trading opportunities. The agent would need access to the following tools: 

• A market data tool that identifies opportunities 

• A CRM tool that provides details of client interests 

• Chat and email notification tools 

Once given the goal, the agent will orchestrate its use of the tools it has access to in order to deliver it. It might call the market data tool to detect opportunities, then the CRM tool to identify clients who may be interested, then send each of them an automated message via their preferred communication channel. 

The key point is that while the core agent might have been developed by the customer, each of the tools can be provided by a separate supplier. 

How an AI agent uses MCP to interact with structured tools across multiple domains

How Do You Build an MCP-Enabled Tool? 

If you are a service provider wanting to package what you do for agent use, a good place to start is by taking an existing API endpoint and repackaging it as a tool. At ipushpull, we have taken our API-driven data sharing and workflow framework and integrated it with agents in exactly this way. 

But how will an agent, powered by a model from a range of different providers like OpenAI or Anthropic, know what your tool does and how to use it? The industry has moved fast to address this challenge with the Model Context Protocol (MCP). This rapidly evolving, vendor-neutral protocol defines a standard way for tools to describe their capabilities. At its core, an MCP contract describes the functions the tool provides and defines how the agent should interact with it, including the parameters to send it and the structure of the data it returns.  

But MCP adds much more value for vendors and their clients. It turns previously opaque API endpoints into self-describing, testable skills. And the pace of evolution is fast - the March 2025 update added support for streaming semantics for long-lived operations. The June 2025 update included support for a dialogue channel for agents to request metadata or negotiate constraints before they act. And MCP lets service providers deliver and evolve functionality through versioned manifests instead of having to maintain bespoke documentation and code snippets. 

These features go a long way towards lowering integration friction. Rather than the existing “here’s an endpoint, good luck” approach, MCP shifts you to “here is an introspectable skill with guardrails”. This lays the groundwork for safer automation. Think of MCP as a USB-C connector for AI – it enables any compatible model to use any compatible tool. 

Exposing your platform as an MCP-enabled tool is the first step toward supporting this new world, but it is not a magic bullet. MCP reduces the risk surface, but it does not eliminate it. There are still significant trust issues, and the risk profile for agentic tools can be higher than for traditional APIs. So it’s critical to ensure that your tools support robust authentication, access controls and full auditability. And be prepared for the same level of vendor onboarding as you get when deploying traditional software and services. To find out more about MCP, visit this page.

To find out more about how ipushpull is addressing these challenges and how we can help you deliver your services into this new world, please get in touch.