Skip to main content
Connect through MCP, the CLI, or your own tools. Your Agent chooses the data; Glasser retrieves it.

Choose an integration method

For Agent frameworks that support remote MCP.
1

Configure the connection

Add this server to your MCP client using Streamable HTTP:
Your product’s account: create a Key and send Authorization: Bearer <your Key>.Your user’s account: connect their Key with the same header, or use MCP browser sign-in with an OAuth-capable client.
2

Give the tools to your Agent

Discover Glasser’s tools with tools/list and register them with your Agent. See the tool reference.
3

Check the connection

Call balance with no arguments. A balance response confirms the connection, even if the balance is zero. This check is free.
Runs use the connected Workspace’s balance. Keep Keys and access tokens out of model messages and frontend code.

Give the Agent a workflow

Search for an Endpoint → Inspect its input and Price → Run to get data. See the Instagram example for the query, matching Endpoint, and input. Search and Inspect are free; your backend applies spending rules before a Run.

Implementation details

Explain when to use Glasser and which tools to call. For CLI-based Agents, start with the Glasser Skill. For custom tools, use your own tool names and Provider preferences.Search requires the user’s request as use_case (CLI: --use-case). Pass its returned task_id to later searches, inspections, and Runs for the same task (CLI: --task).For local CLI development with a user present, glasser login can store a Key through browser sign-in.
Generate an idempotency key for each intended execution and keep it with the request. Retry the same request with the same key:
  • MCP: the idempotency_key tool argument.
  • CLI: --idempotency-key (required with run --json).
  • HTTP API: the Idempotency-Key header.
For QUEUED or RUNNING, read the existing Run until it reaches a terminal state: MCP runs_get, CLI glasser runs get -r <runId> --wait, or HTTP Get Run. Resume the Agent with the result.Check both Run status and provider_response before using output. COMPLETED can include a Provider error; a failed Run can still have a charge.
  • For user-connected accounts, keep credentials separate and select them from the signed-in user’s connection, not from model arguments.
  • Use the Key’s Policy to restrict allowed Endpoints. Enforce per-user spending limits in your backend; a shared Key spends one Workspace balance.
  • Keep the Run ID and charge_usd with your product’s task record.
  • Attach optional customer metadata from your backend for tracking, not access control. With MCP, use the request’s _meta["glasser.ai/metadata"]; metadata is not a model tool argument.