An agent does not need direct warehouse access to answer a useful question; it needs a small set of reliable tools.

Qry endpoints can already serve as those tools because an agent can call one over HTTPS like any other application, or a team can expose the same endpoint through an MCP server it already operates.

Here is a hypothetical example.

One question, one endpoint

Imagine a retailer whose support team uses an agent to investigate customer orders. A support rep asks:

What did customer 11000 order in June, and when did each item ship?

The answer lives in a tested dbt model. Instead of giving the agent warehouse credentials or asking it to generate SQL, the data team publishes a narrow Qry endpoint:

GET /e/acme/customers/order_history

customer_key  integer  required
start_date    date     optional
end_date      date     optional
page          integer  optional

The endpoint is read-only. Its API key can be scoped to this endpoint, its inputs are typed, its response size is capped, and requests are served from the latest successful snapshot rather than sent to the warehouse.

That production interface is the important part because the way an agent reaches it can change without changing the underlying data definition.

An agent can call the endpoint directly

If the agent framework supports ordinary tool functions, the integration is just an authenticated HTTP request:

async function getCustomerOrderHistory({
  customerKey,
  startDate,
  endDate,
}: {
  customerKey: number;
  startDate?: string;
  endDate?: string;
}) {
  const url = new URL(
    "https://api.qry.thedatadavis.com/e/acme/customers/order_history",
  );

  url.searchParams.set("customer_key", String(customerKey));
  if (startDate) url.searchParams.set("start_date", startDate);
  if (endDate) url.searchParams.set("end_date", endDate);

  const response = await fetch(url, {
    headers: {
      Authorization: `Bearer ${process.env.QRY_API_KEY}`,
    },
  });

  if (!response.ok) {
    throw new Error(`Qry request failed: ${response.status}`);
  }

  return response.json();
}

Register that function as a tool in the agent application and describe when it should be used. The agent supplies the customer and date range, while Qry validates the inputs and returns size-limited JSON:

{
  "data": [
    {
      "order_number": "SO43793",
      "order_date": "2026-06-03",
      "ship_date": "2026-06-10",
      "quantity": 1,
      "sales_amount": 3578.27
    }
  ],
  "meta": {
    "page": 1,
    "page_size": 100,
    "has_next_page": false,
    "last_refreshed_at": "2026-07-20T14:05:00Z"
  }
}

The agent can summarize the records for the support rep without seeing the warehouse schema, inventing a join, or starting an open-ended query.

Qry’s generated OpenAPI document can supply the variable types and response schema for agent frameworks that consume API definitions.

This works now and is often the shortest path when one application needs one or two known data tools.

The same endpoint can sit behind MCP

Some teams want tools to be reusable across multiple MCP-compatible clients. They can already add Qry to an MCP server they operate.

The tool handler remains thin. In framework-neutral pseudocode:

server.registerTool(
  "get_customer_order_history",
  {
    description: "Return order lines for one customer and optional date range.",
    inputSchema: {
      customerKey: "integer",
      startDate: "date, optional",
      endDate: "date, optional",
    },
  },
  async ({ customerKey, startDate, endDate }) => {
    const result = await getCustomerOrderHistory({
      customerKey,
      startDate,
      endDate,
    });

    return {
      content: [{ type: "text", text: JSON.stringify(result) }],
    };
  },
);

This gives every connected client a discoverable get_customer_order_history tool while Qry remains the execution layer, so the MCP server does not need warehouse credentials, a SQL engine, or a second copy of the data.

The tradeoff is glue because the team still has to define the tool name, description, and input schema; store and scope the Qry key; map errors; and keep the MCP definition synchronized when the endpoint changes.

That approach is useful today, and it is also the part we can remove.

The native Qry MCP experience

We are building MCP as another interface to active Qry endpoints, derived from the endpoint definition Qry already knows.

In the first version, a team will connect its Qry workspace to an MCP client and the retailer’s active endpoint will appear as a read-only tool with:

Teams will be able to use Qry’s hosted MCP surface or run a small local proxy for clients that expect a loopback or stdio server, and both will forward calls to the existing Cloud endpoint.

There will not be a separate MCP query engine: an MCP call will not open a warehouse connection or bypass the active snapshot, and HTTP and MCP will be two ways to reach the same tested, authenticated, observable interface.

For the hypothetical support team, the setup becomes:

  1. The data team publishes customers/order_history.
  2. Qry derives the tool definition from the active endpoint.
  3. The agent discovers get_customer_order_history.
  4. The tool call follows the same limits and access rules as the HTTPS request.

No handwritten adapter is required.

We are only getting started

The useful thing about Qry today is not an agent-specific feature but the ability to turn trusted warehouse logic into a narrow production interface that direct agent tools and team-built MCP servers can use now.

Native MCP makes the interface easier to discover and reuse, and from there we can carefully extend the same model to operational reads and scoped endpoint management without turning an agent loose on warehouse credentials or secret creation.

The endpoint is already useful, and the native agent experience comes next.