Choose an integration method
- MCP
- CLI
- Custom tools · API
For Agent frameworks that support remote MCP.
Your product
Agent→MCP client
→GlasserMCP tools
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.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
Skill and Agent instructions
Skill and Agent instructions
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.Retries and unfinished Runs
Retries and unfinished Runs
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_keytool argument. - CLI:
--idempotency-key(required withrun --json). - HTTP API: the
Idempotency-Keyheader.
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.Access, spending, and usage tracking
Access, spending, and usage tracking
- 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_usdwith 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.