Avenity AI Visibility MCP
Server Details
Check how well any business appears in AI-powered search (ChatGPT, Perplexity, Gemini) and local results. Returns an Authority Score across 8 pillars: entity clarity, schema, reviews, content depth, citations, GBP, social proof, and AI inclusion. Built for marketing agencies and AI assistants helping SMBs improve local search visibility.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.2/5 across 5 of 5 tools scored.
Each tool serves a distinct step in the AI visibility pipeline: qualification, scoring, competitive analysis, full reporting, and booking. There is no overlap in their purposes.
All tools follow a consistent 'avenity_verb_noun' pattern (e.g., book_consultation, check_visibility), using clear, descriptive verbs and nouns.
With 5 tools, the server is tightly scoped to the AI visibility consulting workflow. Each tool is necessary and no superfluous tools exist.
The tools cover the entire customer journey from gap confirmation to booking, including scoring and competitor analysis. No obvious missing steps for the stated pipeline.
Available Tools
5 toolsavenity_book_consultationARead-onlyIdempotentInspect
Get a Calendly booking link for a free 30-minute AI Visibility consultation with Avenity Business Solutions (Dan).
The consultation is for business owners who have a confirmed AI visibility gap and want to understand the fix and investment required.
This tool is the conversion endpoint of the Avenity agent pipeline: check_visibility → score_business → get_opportunity_report → book_consultation
Use this when:
A client's AI visibility gap is confirmed and they want to act
You've shown the client their score and they're interested
A client asks "how do I fix my AI visibility?"
You want to hand off to a human expert for the close
Args: params (ConsultationInput): Client details. gap_score is optional but improves the booking context shown to Dan.
Returns: str: JSON with: booking_url (str): Direct Calendly link instructions (str): What to tell the client context_for_call (str): What Dan will know before the call audit_url (str): Self-service audit tool URL
Examples: - "Book a consultation for my client who has a 38/100 visibility score" - "How does [company] get help fixing their AI visibility?" - "Connect my client with Avenity"
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about the booking link being for a free consultation, the return structure (booking_url, instructions, context_for_call, audit_url), and that gap_score improves context for Dan. It does not disclose side effects like whether the tool actually books the call or just returns a link, but given the read-only hint, this aligns. No contradiction.
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 well-structured with clear sections: purpose, pipeline context, usage conditions, Args, Returns, and Examples. Every sentence adds value, and the most critical information is front-loaded. No unnecessary words or redundancy.
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 the tool's moderate complexity (1 parameter with nested object, no output schema), the description fully covers what the tool does, when to use it, what parameters are needed, what the return value contains, and provides examples. It integrates well with the sibling tools' pipeline context, making it complete for agent invocation.
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 description coverage is 0%, but the description provides extra meaning: gap_score is optional but improves context, contact_name is owner or contact, and the overall params object is for client details. It compensates for the sparse schema by explaining the purpose of the key parameters and their optionality.
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 a Calendly booking link for a free 30-minute AI Visibility consultation with Avenity Business Solutions. It specifies the target audience (business owners with confirmed AI visibility gap) and distinguishes itself from sibling tools by positioning it as the conversion endpoint of the agent pipeline (check_visibility → score_business → get_opportunity_report → book_consultation).
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 lists explicit conditions for use: when a client's AI visibility gap is confirmed, they've seen their score and are interested, they ask about fixing visibility, or when wanting to hand off to a human expert. It implies the pipeline order but does not explicitly state when not to use this tool or name alternative tools, though the pipeline context indirectly provides guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
avenity_check_visibilityARead-onlyInspect
Check whether a business appears in AI-driven search results when buyers search for their primary service in their city.
This is the first-pass qualifier. If gap_confirmed=True, the business is NOT appearing when buyers search — meaning they are losing customers to competitors right now. This is the core hook for Avenity's service.
Use this when:
A business client asks why they're not getting found online
You need to confirm an AI visibility gap before recommending action
You want to frame the problem before showing a full report
Args: params (BusinessInput): Business details including name, service, city.
Returns: str: JSON with: gap_confirmed (bool): True = business is NOT visible for this query appears_in_ai_results (bool): Whether company name was detected query (str): The exact buyer search query analyzed competitors_appearing (list[str]): Who IS showing up instead result_count_checked (int): Number of results analyzed recommendation (str): Next suggested action for this business
Examples: - "Check if Apex HVAC shows up when people search for HVAC in Houston" - "Is my client visible in AI search?" → call with their company details - "Find out if [company] has an AI visibility gap"
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds context about behavioral implications: if gap_confirmed=True, business is losing customers. No contradictions with annotations.
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?
Well-structured with usage guidelines, args, returns, and examples. Front-loaded with purpose. Slightly lengthy but each section earns its place; could be slightly tighter without examples.
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 single nested param with rich schema, detailed return field list, annotations, and context signals, the description is comprehensive. Examples clarify usage. Output schema not provided but return fields are explicitly described.
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 0% meaning description doesn't detail parameters, but the input schema itself has thorough descriptions for each field. Description repeats 'BusinessInput' and gives examples but adds minimal new semantic value beyond the 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?
Description uses specific verb 'Check whether a business appears in AI-driven search results' and resource 'AI search visibility'. It distinguishes from sibling tools by labeling itself 'first-pass qualifier' and listing siblings for later steps.
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 lists three when-to-use scenarios: client asking why not found, confirming AI visibility gap, framing problem before report. Does not explicitly state when not to use, but 'first-pass qualifier' implies it's step one before other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
avenity_get_competitor_landscapeARead-onlyInspect
Identify which competitors ARE appearing in AI search results when buyers search for a business's primary service in their city.
This is the competitive intelligence layer — it shows a client exactly who is capturing their customers. Highly effective for framing urgency.
Use this when:
A client wants to know who is outcompeting them in AI search
You want to personalize the pitch with specific competitor names
Building context for an opportunity report or outreach message
Args: params (BusinessInput): Business details.
Returns: str: JSON with: query (str): The buyer search query analyzed competitors (list[dict]): Companies appearing, with name and URL your_company_visible (bool): Whether client's company appears gap_summary (str): Plain-English summary of the competitive gap
Examples: - "Who is showing up instead of my client in Houston HVAC searches?" - "Which competitors appear in AI Overview for roofing in Dallas?"
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. The description adds context about return format (JSON with query, competitors, visible flag, gap_summary) and mentions it's 'highly effective for framing urgency', but does not disclose potential latency or prerequisites beyond the schema. This adds value but is not extensive.
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 concise and well-structured: first paragraph states the primary purpose, second adds context, third lists use cases, then Args/Returns/Examples. Every sentence earns its place, and the main function is front-loaded.
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?
The description covers purpose, usage, return format, and provides examples. With an output schema (not shown but indicated) and annotations, it is fairly complete. However, it does not address edge cases like missing data or what happens if the client's company is not found, but this is minor for a read-only intelligence tool.
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?
The input schema provides detailed descriptions for all properties of BusinessInput (city, state, service, website_url, company_name), so coverage is high. The tool description only says 'params (BusinessInput): Business details' and adds no extra meaning. Baseline 3 is appropriate per guidelines.
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 identifies competitors appearing in AI search results for a business's primary service in their city. The verb 'identify' and resource 'competitors in AI search' are specific, and the description distinguishes this tool from siblings like 'avenity_check_visibility' and 'avenity_score_business' by focusing on competitive intelligence.
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 includes a 'Use this when' section with three explicit use cases, such as when a client wants to know who is outcompeting them or to personalize a pitch. It implies when not to use by focusing on competitors rather than own visibility, but does not explicitly name alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
avenity_get_opportunity_reportARead-onlyInspect
Generate a complete, client-ready AI Visibility Opportunity Report for a business. Combines gap confirmation, competitor landscape, dimensional scoring, and revenue impact into a single structured output.
This is the full deliverable — ready to share with a client or use as the basis for a consulting recommendation. It shows the business exactly what they're missing, who's capturing their customers, and what it's worth.
Use this when:
A client needs a full picture before making a decision
You want a single comprehensive output to present
Preparing for a consulting call or proposal
Args: params (BusinessInput): Business details. Include website_url for full dimensional scoring.
Returns: str: Markdown-formatted report including: - AI visibility gap confirmation with buyer query - Competitors appearing in AI search - 4-dimension score breakdown - Estimated monthly revenue at risk - Specific recommendations ranked by impact - Link to book consultation with Avenity
Examples: - "Generate a full AI visibility report for my client" - "What's the complete picture for [company]?" - "Prepare an opportunity report I can show to [client]"
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description does not need to repeat safety traits. It adds transparency by stating the output is a markdown-formatted report with specific sections, and that it is ready to share. No contradictions with annotations.
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 well-structured with clear sections (use cases, args, returns, examples) and is appropriately sized for the complexity of the tool. It could be slightly more concise but is not verbose.
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 the complexity (one parameter that is an object with five fields), the description provides sufficient context: it lists return sections and examples. The output schema is indicated as existing, and the description details the return format.
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 description coverage is 0% meaning the description does not detail the individual parameters. Although the schema itself provides descriptions for each field (e.g., website_url enables deeper scoring), the description only briefly mentions params. It does not compensate for the low coverage.
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 generates a complete, client-ready AI Visibility Opportunity Report, combining multiple components (gap confirmation, competitor landscape, dimensional scoring, revenue impact). It distinguishes itself from sibling tools that are more granular, like avenity_check_visibility and avenity_get_competitor_landscape.
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 lists when to use this tool: when a client needs a full picture, for a single comprehensive output, or when preparing for a consulting call. It implies alternatives are used for narrower scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
avenity_score_businessARead-onlyInspect
Perform a full 4-dimension AI visibility audit of a business's website and return a score from 0–100.
The four dimensions assessed:
Entity Clarity (25 pts): How clearly the website defines who they are, what they do, and where — the foundation AI engines use to understand the business.
Schema & Structure (25 pts): Technical markup (JSON-LD, LocalBusiness schema) that allows AI engines to directly read and cite business data.
Authority & Reviews (25 pts): Publicly visible social proof signals that AI engines use to assess trustworthiness.
Content Depth (25 pts): FAQ content, service pages, and text richness that enables AI engines to generate answers using the business as a source.
Requires website_url in params for full scoring. Without it, returns an estimated score based on search data only.
Use this when:
You need a detailed breakdown to explain the problem to a client
You want to identify the single highest-impact fix
Preparing a client proposal or consulting recommendation
Args: params (BusinessInput): Must include website_url for full scoring.
Returns: str: JSON with total score, label, per-dimension breakdown, and notes.
Examples: - "Score Apex HVAC's AI visibility" (with website provided) - "What's the biggest AI visibility gap for my client?" - "Get a detailed audit of [website]"
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by explaining that website_url enables full scoring, otherwise an estimated score is returned. This behavioral context is not provided by annotations.
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 well-structured, starting with the purpose, listing dimensions, then usage guidelines, parameter note, return format, and examples. It is front-loaded and efficient, though slightly longer than necessary.
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 the tool's complexity (4 dimensions, scoring, optional parameter), the description covers purpose, prerequisites, output format, and use cases. It lacks details on error handling or invalid inputs, but the examples and return description provide adequate context.
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?
The input schema's properties all have descriptions, covering parameter meaning well. The description notes that website_url is required for full scoring, reinforcing but not significantly adding new semantics beyond the schema. Baseline 3 is appropriate given high schema coverage.
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 performs a full 4-dimension AI visibility audit and returns a score from 0–100. It lists the dimensions and differentiates from siblings like avenity_check_visibility by emphasizing its detailed breakdown. The purpose is specific and unambiguous.
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 provides explicit use cases: when a detailed breakdown is needed, to identify the highest-impact fix, or for proposals and consulting recommendations. It implicitly distinguishes from simpler tools, though it does not explicitly state when not to use it.
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.
Discussions
No comments yet. Be the first to start the discussion!