Glasser connects AI agents to paid data APIs through a remote MCP server, an official Skill, a CLI, and an HTTP API. Its data sources cover company and people research, SEO, web search, social media, and local business data. The service uses one Glasser account and Workspace balance. Data calls are pay-as-you-go, with endpoint-specific prices and charge conditions.
This project documents the public Glasser plugin and a reproducible research workflow. The plugin source is available at https://github.com/glasser-ai/plugins under the MIT license. The hosted data service has separate terms and charges. The repository distributes configuration and instructions; it does not contain the Glasser backend or the source code of third-party data providers.
I am sharing this project as a member of Glasser's GTM team. My role here is product documentation and workflow presentation. The implementation is maintained by the Glasser engineering team; this publication does not claim personal authorship of the backend.
A research agent needs more than a plausible answer: it needs a suitable data source, a clear request contract, and an explicit understanding of cost. Different research tasks may need different providers. A workflow that discovers the appropriate endpoint before making a paid request helps keep those decisions visible.
The example in this project is competitor keyword research. The desired output is a sourced comparison of keyword opportunities for a specific domain and market. The researcher must first define the domain, geography, and desired result. These are user choices, not values the agent should invent.
plugins/glasser/plugin.json: portable plugin metadata.plugins/glasser/skills/glasser/SKILL.md: instructions for using Glasser in agent workflows.plugins/glasser/mcp.json and .mcp.json: remote MCP configuration for supported clients.plugins/glasser/rules/glasser-spending.mdc: instructions for Cursor workflows.The remote MCP endpoint is https://api.glasser.ai/mcp. The official documentation describes OAuth authentication for compatible clients and a Key-based setup for clients without OAuth. Compatibility and authentication must be checked in the client being used; the existence of a plugin file alone does not prove that every client can load it.
Steps about selecting scope, asking for approval, and presenting a comparison are the workflow recommended in this publication. The linked official documentation defines Glasser's actual API and authentication behavior.
Use Glasser to research competitor keywords for the domain and market I provide. First identify a relevant endpoint, inspect its required inputs and current charge conditions, and show me the proposed small request and price before any paid execution. After I approve it, report the returned keyword evidence, the provider, the actual charge, and any limits in the data. Do not invent missing metrics or expand the request without asking.
Expected output is a research plan followed, after approval and execution, by a sourced keyword comparison. This publication provides no fabricated sample metrics, performance benchmarks, or claimed execution results. For an official worked scenario, see https://glasser.ai/tutorial/analyze-competitor-keywords . Other documented scenarios include overseas buyer research and local business lists at https://glasser.ai/tutorial/find-overseas-buyers and https://glasser.ai/tutorial/local-business-list .
The plugin's MIT license applies to the distribution package. It does not make third-party data requests free. Inspect the selected endpoint for its current price and outcome-specific conditions; do not assume that every empty result or failed request has the same charge.
An authenticated request goes to Glasser and the selected data service as described by the service documentation and privacy policy. The host agent client may also process the prompt and returned data under that client's own policies. Use only data appropriate for the research task and authorized for the selected services.
This publication describes the public project and its documented workflow. It does not establish end-to-end compatibility with an untested client, disclose private credentials, or claim that the underlying commercial service is open source. Client integration tests and paid endpoint evaluation should be recorded separately with their actual environment and results.