Brand Intelligence MCP
Server Details
Domain & brand intelligence: company enrichment, tech stack detection, brand research.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- FoundryNet/brand-intel-mcp
- GitHub Stars
- 0
- Server Listing
- Brand Intelligence MCP
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 7 of 7 tools scored. Lowest: 3.9/5.
Each tool targets a distinct purpose: bulk enrichment, brief summary, full daily brief, domain age, full profile, network info, and tech stack. No two tools overlap in functionality.
All names use snake_case consistently, but not all follow a strict verb_noun pattern (e.g., 'brief_summary' and 'daily_brief' are noun-based). The pattern is predictable and readable.
Seven tools cover the domain of brand intelligence efficiently, each addressing a specific need without redundancy. The count feels well-scoped for the server's purpose.
The toolset covers core operations: bulk enrichment, individual profiling, domain age, tech stack analysis, daily briefs, and network info. No obvious gaps for the stated domain.
Available Tools
7 toolsbatch_enrichAInspect
Enrich many companies or domains at once for bulk lead enrichment and company research — returns an array of full profiles (registration age via WHOIS/RDAP, tech-stack detection, hosting, SSL/CT details). The volume play for sales agents. Up to 50 domains per call, served from cache where fresh.
PAID: $0.01 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; settle 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 | payment transaction reference, 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: batch operation, 50-domain limit, caching, paid pricing ($0.01/domain, min $0.05, free allowance), payment flow via 402 and payment_tx, and Bearer key bypass. It provides comprehensive behavioral context.
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 then provides necessary details on pricing and payment. While slightly verbose, every sentence adds value. Could be more concise but still 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 the output schema exists, the description still covers all needed context: operation, constraints, pricing, authentication, caching. It is complete for an agent to select and invoke the 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%, so baseline is 3. The description adds context beyond schema: domains max 50, agent_id scopes free-tier, payment_tx explained in payment flow. This extra meaning justifies a score above baseline.
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 'enrich' and the resource 'companies or domains', and details the output as an array of full profiles including registration age, tech-stack, hosting, SSL/CT. It distinguishes from siblings like 'tech_stack' or 'domain_age' by emphasizing bulk operation for sales agents.
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 indicates this is 'the volume play for sales agents' and provides pricing and payment flow, implying use for bulk enrichment. However, it does not explicitly state when not to use it or suggest alternatives like single-domain tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brief_summaryAInspect
Get the top 5 signals from today's brief as structured JSON — a cheap sample of the full daily_brief. Returns the day's highest-priority items (no prose) so an agent can decide whether to buy the full brief.
PAID: $0.50 (vs the full daily_brief price). Defaults to today (UTC). On a 402, settle the returned payment memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | payment transaction reference, 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?
Discloses cost ($0.50), default date (today UTC), 402 error handling with payment_tx, and alternative auth (bearer key). Comprehensive for a tool with no 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?
Front-loaded with main purpose, but second paragraph on payment is slightly verbose. Still well-structured with clear 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?
Covers all essential aspects: purpose, output format, payment, error handling, default behavior, authentication. No gaps given sibling context and output schema.
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 3. Description adds context: agent_id scopes free-tier counter, payment_tx used on re-call after 402. Adds meaningful 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 retrieves top 5 signals from today's brief as structured JSON, a cheap sample of full daily_brief. Distinguished from sibling tool by specifying it's a preview.
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?
Describes when to use (to decide whether to buy full brief) and payment flow on 402. Implicitly contrasts with daily_brief but lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_briefAInspect
Get the curated daily brand & domain intelligence brief — the day's company-enrichment activity in one package: an activity summary (domains profiled / enriched in 24h), notable findings (recently registered domains via WHOIS, interesting tech-stack detection / hosting), and cached domains whose SSL certs expire soon (next 30 days). For company research and lead enrichment. Each brief carries a cryptographic provenance attestation so a buyer can verify it was produced by this server, unaltered.
PAID: $5 per brief. Defaults to today (UTC); a brief expires at the next midnight UTC. On a 402, settle the returned payment memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | payment transaction reference, when re-calling after a 402. | |
| stripe_token | No | Stripe Checkout Session id (cs_…), when re-calling after paying the Stripe payment link (alternative payment rail). Can also be supplied via the X-Stripe-Token header. |
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 are provided, so the description bears full burden. It fully discloses that the tool is paid ($5 per brief), defaults to today UTC, expires at next midnight UTC, offers provenance attestation, and details the payment and re-call process, including the Authorization header bypass.
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 a single dense paragraph that efficiently conveys purpose, contents, payment, and constraints. It is front-loaded with the key action. Could be slightly improved with bullet points, but it is clear and not overly 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 (4 parameters, payment handling, expiration, auth bypass) and the presence of an output schema, the description covers all essential aspects: what the brief contains, how to pay, how to bypass payment, and expiration. It does not describe the output schema, which is acceptable per rules.
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 significant context: explains that 'agent_id' scopes the free-tier counter, and clarifies the purpose of 'payment_tx' and 'stripe_token' in re-calling after a 402. This exceeds the schema's basic 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 tool retrieves a 'curated daily brand & domain intelligence brief' and lists specific contents (activity summary, notable findings, cached domains). It distinguishes itself from siblings like 'batch_enrich' and 'domain_profile' by focusing on a daily summary.
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 clear context: 'For company research and lead enrichment.' It also explains the payment flow (402 handling, payment_tx, stripe_token) and an authorization bypass. However, it does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain_ageAInspect
Look up a domain's registration age — registration date, age in days, and expiry — via WHOIS/RDAP. Domain intelligence for company research and lead enrichment. 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?
No annotations provided, but description discloses the tool is free, uses WHOIS/RDAP, and caches results. It implies read-only behavior. Annotations could add safety cues, but the description is sufficient.
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?
Three sentences, no fluff, front-loaded with purpose. Every sentence adds value: what it does, use cases, pricing, and caching behavior.
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 single-parameter tool with an output schema, the description is complete. It explains functionality, data sources, caching, and cost, leaving 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?
The only parameter 'domain' is fully described in the schema (100% coverage). The description adds an example ('openai.com') and clarifies the format, 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 looks up domain registration age, registration date, age in days, and expiry via WHOIS/RDAP. It also specifies use cases (company research, lead enrichment), distinguishing it from sibling tools like domain_profile or tech_stack.
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 mentions it is FREE with no payment or consumption, and explains caching behavior on cache miss. It does not explicitly compare to alternatives, but the context is clear for its intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain_profileAInspect
Profile a company or domain for company enrichment and lead enrichment:
registration age and registrar (WHOIS/RDAP), nameservers, SSL issuer +
expiry (SSL/CT logs), tech stack detection (CMS, frameworks, hosting),
Wayback history, and social profiles. Domain intelligence and company
research in one call — automatically enriched with cross-server intelligence
from the FoundryNet Data Network (financial signals, patents, regulatory/
compliance actions, open-source risk, and domain threat reputation) when
available, returned under network_intelligence. Served from a 7-day cache;
a miss enriches live.
PAID: $0.05 per query after a daily free allowance (10/day). On a 402, settle the returned payment 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 | payment transaction reference, 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?
Detailed transparency on data sources, 7-day cache, live enrichment on miss, payment model with 402 handling, and auth via agent_id or Bearer token. No annotations provided, so description fully covers behavioral traits.
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?
Structured and front-loaded with core purpose, followed by caching and payment details. Slightly verbose but each sentence adds essential context. Could be tightened but overall effective.
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 exists, description covers all necessary aspects: input domain, data fields, caching behavior, payment flow, and authorization. No gaps for an AI agent to understand usage.
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%, delivering baseline. Description adds value by explaining payment_tx usage in context of 402 errors and agent_id for scoping free allowance, beyond 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?
Clearly states it profiles a company/domain for enrichment, listing many data points (WHOIS, SSL, tech stack, etc.). Distinguishes from siblings by being a comprehensive all-in-one tool.
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?
Describes caching and payment but no explicit guidance on when to use this tool vs. specific siblings like domain_age or tech_stack. Implies broad use but lacks direct alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_infoAInspect
Get FoundryNet Data Network info and provenance attestation details. FREE.
Returns how to attach verifiable provenance attestation to your agent's domain/brand intelligence, the attestation service endpoint, and the sister data servers (gov-contracts, patent-intel, financial-signals, weather-intel, cyber-intel, compliance, academic-intel, fact-check, oss-intel, social-intel).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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, so description carries full burden. It discloses the tool returns specific data (attestation details, endpoints, server list) but does not mention potential side effects, rate limits, or authentication requirements. 'FREE' may imply no cost but is ambiguous.
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, with a clear first sentence defining the tool's purpose and a second sentence detailing what it returns. The use of a bulletized list in prose could be slightly more structured, but overall no wasted words.
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 zero parameters and the existence of an output schema, the description adequately covers the tool's functionality by listing return components. It does not discuss limitations or prerequisites, but for a simple info-getter, this is acceptable.
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 tool has zero parameters and 100% schema coverage, so the description does not need to add parameter info. The baseline score of 4 is appropriate, and the description adds value by explaining what the tool returns.
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 retrieves FoundryNet Data Network info and provenance attestation details, listing specific elements returned (attestation endpoint, sister data servers). It distinguishes from siblings by focusing on network metadata rather than data enrichment or domain analysis.
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 mentions the tool is 'FREE' and lists what it returns, giving implicit context for when to use it (e.g., to get network info). However, it does not explicitly state when not to use it or compare to alternatives like batch_enrich or domain_age.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tech_stackAInspect
Analyze a domain's tech stack — frameworks, CMS, hosting provider, analytics, and platform signals — via tech-stack detection over homepage and HTTP response-header fingerprinting. Domain intelligence for company research, competitive analysis, and lead enrichment.
PAID: $0.01 per query after the daily free allowance (10/day). On a 402, settle the returned payment 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 | payment transaction reference, 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 were provided, so the description carries full burden. It discloses the payment model (paid after free allowance), error handling (402 with payment_tx), and authentication bypass. It does not mention rate limits or data retention, but the key behavioral aspects are covered.
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 structured into two logical paragraphs: purpose and pricing/error handling. It is mostly concise, though the payment explanation could be slightly tighter. Front-loaded with the main purpose.
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 doesn't need to explain return values. It covers purpose, method, pricing, error handling, and parameter context. It is complete for an agent to understand how and when to use the 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%, but the description adds value by explaining the payment_tx parameter in the context of error recovery and free-tier scoping via agent_id. This goes beyond the 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 tool analyzes a domain's tech stack including frameworks, CMS, hosting, analytics, and platform signals. It specifies the method (homepage and HTTP response fingerprinting) and use cases (company research, competitive analysis, lead enrichment). This distinguishes it from sibling tools 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 clear context for when to use the tool (e.g., company research, competitive analysis) but does not explicitly compare to siblings or say when not to use it. However, the purpose is distinct enough that an agent can infer appropriate usage.
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!
Your Connectors
Sign in to create a connector for this server.