Brand Intelligence MCP
Server Details
Domain & brand intelligence: company enrichment, tech stack detection, brand research.
- 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.4/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: batch enrichment, domain age, full profile, and tech stack. There is no overlap; agents can easily select the appropriate tool.
Three tools use the 'domain_' prefix with a clear noun, and 'batch_enrich' deviates slightly but still follows snake_case and a verb-noun pattern. Overall consistent.
Four tools is well-scoped for a brand intelligence server, covering key queries without being too few or too many.
The set covers batch enrichment, age, full profile, and tech stack. Minor gaps like dedicated social profile or historical WHOIS exist, but core needs are met.
Available Tools
4 toolsbatch_enrichAInspect
Enrich many domains at once and get back an array of full brand-intel profiles — the volume play for sales / lead-enrichment agents. Up to 50 domains per call, served from cache where fresh.
PAID: $0.01 USDC per domain, minimum $0.05, after the daily free allowance. The exact price is computed from the (deduped) domain count and returned in the 402; pay that memo and re-call with the SAME domains plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | array of domains, e.g. ["stripe.com", "plaid.com"]. | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully covers behavior: returns array of profiles, serves from cache, pricing details, payment flow, and auth bypass. No contradiction since annotations are absent.
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: purpose first, then pricing/payment. Slightly verbose with payment details, but every sentence adds value. Could be tightened slightly, but remains clear.
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 output schema existence, description explains return format ('array of full brand-intel profiles'). Covers pricing, caching, payment flow, auth bypass, and domain limits. No missing context for a batch enrichment 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?
Schema coverage is 100%. Description adds meaning: domains limited to 50, deduped for pricing; agent_id scopes free-tier; payment_tx used for re-call after 402. Provides critical usage context 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 it enriches many domains at once and returns full brand-intel profiles, explicitly calling it a 'volume play' for sales/lead-enrichment. It distinguishes from sibling tools (domain_age, domain_profile, tech_stack) by being batch-oriented.
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?
Provides detailed when-to-use guidance: 'the volume play for sales / lead-enrichment agents.' Explains pricing ($0.01 per domain, min $0.05, free allowance), the 402 payment flow (pay memo, re-call with payment_tx), and optional authorization bypass. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain_ageAInspect
Registration date, age in days, and expiry for a domain. FREE — no payment and no free-tier consumption. (On a cache miss it does a quick WHOIS lookup and caches it.)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | the domain to check, e.g. "openai.com". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It discloses caching behavior (lookup on cache miss, cache result) and cost (free). It does not mention potential failures or rate limits, but for a simple tool this is adequate.
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 lists outputs, second explains cost and cache behavior. No wasted words, highly efficient.
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?
Output schema exists, so description need not detail return values. It covers inputs, outputs, cost, and behavior completely for a tool with one parameter.
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 no additional meaning beyond the schema's description of the 'domain' parameter (e.g., format example). The extra context about free and caching is not parameter-specific.
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 returns registration date, age in days, and expiry for a domain. It distinguishes from siblings like domain_profile (more comprehensive) and tech_stack (technology analysis) by focusing specifically on domain age and expiry.
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?
It explicitly notes the tool is free with no payment or free-tier consumption, suggesting when to use it. However, it does not provide explicit when-not-to-use guidance or compare with siblings like domain_profile for more detailed information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain_profileAInspect
Full brand-intelligence profile for a domain: registrar + registration / expiry dates, nameservers, SSL issuer + expiry (from CT logs), detected tech stack + CMS + hosting provider, Wayback history (first snapshot + total snapshots), and social profiles. Great for company enrichment and brand research. Served from a 7-day cache; a miss enriches live.
PAID: $0.02 USDC per query after a daily free allowance (10/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. Pass agent_id to scope your free allowance; an Authorization: Bearer fnet_ key bypasses the paywall.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | the domain to profile, e.g. "stripe.com". | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: 7-day cache, free allowance, payment requirement after 10/day, and retry flow with payment_tx. This provides the agent with necessary operational details beyond just stating the output.
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 paragraphs, front-loading the core value proposition and data points, then explaining payment. Every sentence adds value, though it could be slightly more structured (e.g., separate sections).
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 an output schema exists (so return values don't need specification), the description covers input params, caching, payment, and usage context. It lacks error handling details beyond 402, but is otherwise complete for a data enrichment 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?
Schema coverage is 100% with descriptions for all parameters. The description adds context for 'agent_id' (scopes free-tier counter) and explains the payment flow for 'payment_tx', but these are also captured in schema descriptions. At baseline 3, the description adds limited extra value.
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 defines the tool's purpose: 'Full brand-intelligence profile for a domain' with a specific list of data points (registrar, SSL, tech stack, Wayback, social). It distinguishes from siblings like 'domain_age' (likely just age) and 'tech_stack' (just tech) by offering a comprehensive profile.
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 states the tool is 'great for company enrichment and brand research,' giving clear usage context. It also explains caching, free allowance, and payment flow, guiding when to use and how to handle paywalls. However, it does not explicitly exclude use cases or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tech_stackAInspect
Detected technologies for a domain — frameworks, CMS, hosting provider, analytics, and platform signals — from homepage + response-header heuristics. Tech stack detection for competitive and sales research.
PAID: $0.01 USDC per query after the daily free allowance (10/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | the domain to inspect, e.g. "shopify.com". | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: detection method (homepage + response headers), payment model ($0.01 USDC after free allowance), and the 402 retry flow with payment_tx. This is comprehensive.
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 front-loaded with purpose and is efficient. The payment details are necessary but slightly verbose. No wasted sentences overall.
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 presence of an output schema, the description sufficiently explains what the tool returns and how it operates. It also covers edge cases like payment. No gaps remain.
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%, and the description does not add significant meaning beyond the parameter descriptions already in the schema. It mentions agent_id scopes free counter, but that's redundant with 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's purpose: 'Detected technologies for a domain — frameworks, CMS, hosting provider, analytics, and platform signals'. It uses specific verbs and resource, distinguishing it from siblings like domain_age or domain_profile.
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 context for use ('competitive and sales research') and includes payment details but does not explicitly tell when not to use or compare to alternatives. It implies appropriate context but lacks exclusions.
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!