AI visibility checks, software recommendations and tool comparisons from measured AI answer data
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 4 of 4 tools scored.
Each tool targets a distinct query type: compare for side-by-side comparison of two products, find_tools for category recommendations, get_ai_index for detailed AI ranking data, and get_facts for factual product details. No two tools have overlapping purposes.
Tool names mostly follow a verb_noun pattern (find_tools, get_ai_index, get_facts), but 'compare' is a lone verb without underscores. The inconsistency is minor and does not hinder readability.
Four tools is an ideal count for this server's scope—covering discovery, comparison, ranking, and fact-checking. Each tool earns its place without redundancy or bloat.
The tool surface covers the core workflows: finding tools, comparing them, getting AI recommendation data, and verifying facts. A minor gap is the absence of a tool to list all categories or products, but this is partially addressed by calling get_ai_index with no category.
compareAInspectCompare software/tools side by side — a fact-by-fact comparison of two products (pricing, features, integrations, limits) with source URLs and verified dates for every claim. Use for "X vs Y" software comparison questions. Accepts product names or domains; pair order does not matter.
| Name | Required | Description | Default |
|---|---|---|---|
| product_a | Yes | First product name or domain. | |
| product_b | Yes | Second product name or domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool provides 'source URLs and verified dates for every claim' and that pair order is irrelevant, adding useful behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the main action ('Compare software/tools side by side') and packs essential details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the tool's purpose, usage, and output characteristics (source URLs, verified dates). It is complete enough for most use cases, though it could mention error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by confirming that parameters accept product names or domains and that order does not matter, which surpasses the brief schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compare', the resource 'software/tools', and the scope 'side-by-side fact-by-fact comparison' with specifics like pricing, features, integrations, limits. It distinguishes from siblings (find_tools, get_ai_index, get_facts) by focusing on product comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for "X vs Y" software comparison questions' and clarifies that 'pair order does not matter.' It provides clear context but does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_toolsAInspectSoftware recommendations backed by measured AI answer data: find the best software/tools for a category or job, ranked by how often AI assistants (ChatGPT, Claude, Gemini, Perplexity) actually recommend them in real buyer-style queries — not by ads or affiliate placement. Use when asked "what software/tool should I use for X", "best X tools", or for vendor-neutral software recommendations. Pass the category in plain words (e.g. "uptime monitoring", "CRM for freelancers"); it is fuzzy-matched against published Index categories, and near-miss inputs return suggested categories to retry with. Returns ranked products with recommendation share %, 4-week trend, and per-engine breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max recommendations to return (default 10, max 50). | |
| category | Yes | Software category or job to find tools for, in plain words (e.g. "ci/cd", "landing page builders"). | |
| constraints | No | Optional buyer constraints (e.g. "open source", "free tier", "self-hosted"). Echoed back with the data for the caller to weigh — not yet applied server-side. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the ranking method (not ads/affiliates), return fields (share %, trend, per-engine breakdown), and fuzzy matching behavior. Could mention authentication or rate limits but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with key value. A bit long but every sentence adds necessary information. Could be slightly more concise but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return values: ranked products with share %, trend, per-engine breakdown. Covers parameters and usage well. Good completeness for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% means baseline 3. Description adds meaning: explains fuzzy matching for 'category', default/max for 'limit', and that 'constraints' are echoed back not applied. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides software recommendations based on measured AI answer data, for a specific category or job. It distinguishes from siblings by focusing on ranking by AI recommendations rather than ads or affiliates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when asked...' with examples like 'what software/tool should I use for X'. Mentions fuzzy matching and near-miss inputs return suggestions. No explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ai_indexAInspectAI visibility check — which software AI recommends for a category. Returns the full AI Recommendation Index for one software category: the complete measured ranking of products AI assistants (ChatGPT, Claude, Gemini, Perplexity) recommend, with recommendation share %, average answer position, per-engine breakdown, 4-week trend, sample size, and methodology. Use to answer "does AI recommend " (look up its row and rank), "who is winning AI recommendations in ", or to cite AI recommendation-share data. Pass category in plain words or as a slug; omit it (or pass "categories") to list all published categories.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category in plain words or slug form (e.g. "uptime monitoring", "ci-cd-tools"). Omit or pass "categories" to list every published category with sample sizes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes output components and behavior (returns ranking, shares, per-engine, trend). Lacks explicit idempotency or safety statement, but clearly a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then expands with details and examples. Every sentence adds value, no waste. Well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete description for a tool without output schema. Covers what is returned (ranking, shares, per-engine, trend, sample size, methodology), how to use, and examples. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining plain words vs slug and special value 'categories' for listing all. Baseline 3 plus extra context justifies 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'get' and the resource 'AI Recommendation Index' for a category. Provides specific details on what is returned and examples of use. Distinguishes from siblings listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: to answer 'does AI recommend <product>' or cite recommendation data. Explains how to pass category and omit for all. Does not specify when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_factsAInspectCanonical software product facts with sources — pricing, features, integrations, platform, and limits, where every fact carries a source URL and a last-verified date. Use to verify software claims (e.g. current pricing) or to gather grounded data before recommending or comparing tools. Accepts a product name or domain (e.g. "hubspot.com").
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product name or canonical domain, e.g. "hubspot.com". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that results include source URLs and last-verified dates, indicating data freshness and verifiability. No annotations provided, but the description conveys the read-only, authoritative nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines the tool's offering, second provides use cases and input format. No wasted words, front-loaded with key value proposition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool, the description fully explains what facts are provided (with sources and dates) and when to use it. No output schema needed given the clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds an example ('hubspot.com') and clarifies the parameter accepts product names or domains, enhancing usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides canonical software product facts with sources, covering pricing, features, integrations, platform, and limits. It distinguishes from siblings by focusing on verified facts, not comparison or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use for verifying software claims or gathering grounded data. While it does not provide exclusions, the context signals sibling tools that cover alternative actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!