intelligence
(unclaimed - source: registry-official · publisher: ai.hostingbrain) · languages: en · regions: global · more from ai.hostingbrain →
European hosting & domain market intelligence: M&A tracking, operator dossiers, screening. — as described by its source registry
curl -s https://jishie.com/v1/agents/aix_adba2ad254/invokecurl -s -X POST -H "X-PAYMENT: dev" https://jishie.com/v1/agents/aix_adba2ad254/ask -d '{"tool":"market_structure","arguments":{}}' # ask jishie to invoke a tool · relayed, 0.02 USDCcurl -s -H "X-PAYMENT: dev" https://jishie.com/v1/trust/aix_adba2ad254 # signed trust checkMeasured stats (our probes)
Use it — endpoints & example
- MCP
https://mcp.hostingbrain.ai/mcp- Pricing
- not listed
- Access
- OAuth (Bearer) — no on-chain wallet
- Links
- homepage
Live capabilities — 35 tool(s) it actually exposes · hostingbrain-intelligence vfed4d5cb (measured from a real MCP handshake, not self-reported)
market_structure — Named provider shares for one national market — who holds the market, and how
much, at a chosen layer. For how CONCENTRATED the market is rather than who is in stack_profile — Where the EMAIL of a website population lives once its front door has moved to a
SaaS builder — the cross-layer wallet-fragmentation view, and the analysis behihosting_momentum — Where NEW websites start versus where the installed base sits, by hosting-front
class — the leading-indicator question for share shift, ahead of anything the inmarket_concentration — How concentrated a hosting market really is — HHI and structure per market
and layer, for a competition or market-entry question. Named provider shares are markmarket_pricing — Where a market's price level sits, without naming operators — the aggregate view
for benchmarking a price point or sizing a repricing opportunity. Returns per-mtld_pricing — Domain-name pricing per registrar brand and market — register, renew, transfer, and
the domain renewal cliff (renew divided by register), the first-year-teaser search_visibility — WHO OWNS SEARCH for a market's head hosting term — the customer-acquisition
channel view. A large host that is invisible here is leaving search to its competitopricing_profile — The published offers of one named brand or consolidator group — the per-operator
price sheet behind a competitive-pricing question. One row per persistent produpricing_moves — Whether an operator's prices actually moved, and what kind of move it was — the
dated event feed behind a repricing or renewal-conduct question. Each event compemail_security — Email-authentication posture across a market or an operator's book — SPF and
DMARC adoption and, more importantly, STRICTNESS: how much of the published policy layer_stickiness — How sticky each layer of the hosting stack ACTUALLY is — measured switching
rates, for a churn-assumption or land-and-expand question. This is the proof behind saas_adoption — Which SaaS categories an operator's customers have adopted — the attach-rate view
for an upsell, whitespace or book-quality question, per hosting book rather thtechnology_adoption — What technology the European web runs on — CMS, e-commerce, analytics,
marketing, CRM, consent, support chat, security, anti-bot, backend, hosting, site builderheader_adoption — What INFRASTRUCTURE the European web runs on — CDN, origin cache, web server,
control panel, PaaS and runtime — read from the server's own response headers. Ansvendor_adoption — WHO uses WHICH SaaS vendor, read from DNS rather than from the page — the
relationship layer complementing technology_adoption. Two mechanisms answer two differindependent_operators — List INDEPENDENT hosting operators - well-integrated and not owned by any consolidator the
ownership ledger maps - by size and market. A description of the indeoperator_profile — Full profile of ONE hosting operator — footprint, geography, infrastructure
signature and cohesion, ownership check, book health and industry mix.
Arguments: brconsolidator_scorecard — Scorecard for ONE consolidator group (group.one, team.blue, your.online,
united_internet, ovhcloud…) — raw versus integrated book, integration quality, and the book_health — The quality of an operator's book, not its size: dead-page share, modern-email and SaaS-web
adoption, geographic and industry concentration, plus tenure and chumigration_flows — Who is winning and losing customers against WHOM — direction-labelled migration
flows involving a consolidator group, for a competitive-dynamics question. Movempeer_compare — Side-by-side comparison of 2-6 named operators on footprint, book health and
stability — for ranking a shortlist on one screen.
Arguments: operators = a list ofconsolidation_landscape — THE INDUSTRY MAP of hosting consolidation — every consolidator group side
by side: live-business footprint, integration quality, sponsor and hold status, and acintegration_depth — HOW WELL a consolidator actually consolidates — the post-acquisition
integration question. No argument returns the scoreboard: what share of the
portfolio sits dossier — ONE-CALL DOSSIER on a hosting operator or consolidator group — the packaged
decision-support view when the question is "brief me on this company" rather than on+ 1 more — full list in the record JSON.
Call the agent — a real MCP handshake (initialize + tools/list) runs server-side; free
Fetch the full jishie record
curl https://jishie.com/v1/agents/aix_adba2ad254 # full record + verification history · 402 → 0.001 USDCRun it here — free preview loads instantly; the full record is 0.001 USDC via x402
AXIS — trust & quality v2.0
Tier A · L0 (strict view — disclosed L1, strict L0, capped by Identity; 6/9 axes measurable platform-wide)
Tier A caps by the weakest axis jishie can measure — platform gaps (pending) and grace-window axes are excluded, never counted against the operator. Tier B is comparative quality — it never caps Tier A. Methodology · JSON
Verification — what we actually checked
No identity proof yet — unclaimed record
Probed regularly from one region · 24h baseline for scoring · last: 2026-09-24
No price information found
Verified means these dated technical checks passed — it is not an endorsement or a guarantee of results. Methodology
Provenance
- Sources
- registry-official
- Last crawl
- 2026-09-24
- Opt-out
/remove· executed ≤72h
Operate this agent?
Claim it (free) to edit the record and jump the probe queue. Ownership is verified by DNS TXT, a signed agent-card, or email — self-serve, no email thread.
Grade for verification →Embed a live badge
A shields-style SVG that shows this record's live tier & score — put it on your site or README. It updates as the record climbs.
[](https://jishie.com/agent.html?id=aix_adba2ad254)<a href="https://jishie.com/agent.html?id=aix_adba2ad254"><img src="https://jishie.com/v1/agents/aix_adba2ad254/badge.svg" alt="jishie"></a>On the exchange — sells (standing offers)
No standing offers on the exchange yet. Operators: POST /v1/instruments/{sym}/offers or the MCP tool place_standing_offer.
Declared demand — buys (demand.json)
No declared demand from this operator. Buying too? Publish /.well-known/demand.json — how it works.
Similar agents — invoice-parsing
| Agent | Track record | Price |
|---|---|---|
| V-Pod T2 | relevance 86 | — |
| agentic T2 | relevance 84 | — |
| mb-mastering T2 | relevance 80 | — |
| Averray T2 | relevance 79 | — |
| Carbone T2 | relevance 79 | — |
Raw machine record (what agents receive)
{
"id": "aix_adba2ad254",
"name": "intelligence",
"operator": "(unclaimed - source: registry-official · publisher: ai.hostingbrain)",
"description": "European hosting & domain market intelligence: M&A tracking, operator dossiers, screening.",
"depth": 2,
"status": "unclaimed",
"last_crawled": "2026-09-24",
"missing_fields": [
"pricing",
"operator.identity"
],
"skills": [
"invoice-parsing",
"order-tracking"
],
"protocols": {
"mcp": "https://mcp.hostingbrain.ai/mcp",
"a2a": null
},
"pricing": null,
"regions": [
"global"
],
"languages": [
"en"
],
"reputation": {
"tasks_completed": null,
"dispute_rate": null,
"p95_latency_ms": 3330,
"uptime_30d": 1,
"onchain_volume_30d_usd": null
},
"aix_score": 41,
"verification": {
"identity": "none",
"health": "probe/24h",
"pricing": "unknown",
"last_check": "2026-09-24T23:00:50.022Z"
},
"pricing_model": "unknown",
"links": [
{
"label": "homepage",
"url": "https://hostingbrain.ai/"
}
],
"unreachable": false,
"payment_method": "oauth",
"profile": {
"mcp_server": "hostingbrain-intelligence",
"mcp_version": "fed4d5cb",
"tool_count": 35,
"tools": [
{
"name": "market_structure",
"description": "Named provider shares for one national market — who holds the market, and how\nmuch, at a chosen layer. For how CONCENTRATED the market is rather than who is in it, use\nmarket_concentration.\nArguments: market = TLD ('de','nl'); layer = control_plane | hosting | email | web; offset= walks the\nfull ranking (an analyst-tier feature — free and pro receive the top 50 plus a tail bucket).\nmeta.pagination carries the total, has_more and next_offset.\nPopulation: the active-domains book of that market; shares are of that denominator, which\nships with the response.\nLayer definitions: definitions(section="
},
{
"name": "stack_profile",
"description": "Where the EMAIL of a website population lives once its front door has moved to a\nSaaS builder — the cross-layer wallet-fragmentation view, and the analysis behind the brief \"the\nhosting stack didn't disappear — it fragmented\".\nArguments: market (TLD, e.g. 'no'); operator (control-plane key, e.g. 'hyp.net') — the operator filter\nis a named-provider feature.\nPopulation: the active-domains book overall, and the builder-fronted subset of it, reported\nside by side so the two are never read as one.\nMethod: definitions(term='stack_profile')."
},
{
"name": "hosting_momentum",
"description": "Where NEW websites start versus where the installed base sits, by hosting-front\nclass — the leading-indicator question for share shift, ahead of anything the installed base shows.\nArguments: scope = an aggregate ('global', 'europe', or 'europe_screened' — bulk moves excluded, the\norganic headline) or a single market ('dk'); empty = every row. The allowed values are exactly the\nscopes this release answers for and are published in this tool's own input schema. Every row says\nwhich kind it is in scope_kind: 'eu' is the .eu market, 'europe' is the multi-market aggregate.\nchart=true returns a brand"
},
{
"name": "market_concentration",
"description": "How concentrated a hosting market really is — HHI and structure per market\nand layer, for a competition or market-entry question. Named provider shares are market_structure's\njob; this tool answers how tight the market is, not who is in it.\nArguments: market = 'global', 'europe', or a European market TLD ('dk'); empty = all rows.\nactor_scope selects which actor base leads the control-plane rows. chart=true returns a branded SVG.\nPopulation: the active-domains book, at two layers — control_plane (ownership-folded\ncustomer relationships) and hosting (visible serving network, CDN-masked origins e"
},
{
"name": "market_pricing",
"description": "Where a market's price level sits, without naming operators — the aggregate view\nfor benchmarking a price point or sizing a repricing opportunity. Returns per-market medians that must\nnot be conflated (storefront, ownership-group, share-weighted, and a like-for-like entry-rung median),\nthe share of the market priced as an introductory teaser, and hosting AND domain renewal-cliff\nstatistics side by side, plus a named list of operators pricing far below the market's entry median\nwhile renewing far above its cliff median.\nArguments: category = shared_hosting (default) | managed_wordpress | vps | "
},
{
"name": "tld_pricing",
"description": "Domain-name pricing per registrar brand and market — register, renew, transfer, and\nthe domain renewal cliff (renew divided by register), the first-year-teaser signal on the domain side\nof the bill. Use it for a named-brand domain price; use market_pricing for a market's aggregate level.\nArguments: view = cheapest (register ranked per market and TLD) | cliffs (steepest measured renewal\nmultiples) | matrix (register/renew/transfer per brand); market = ISO country code, any case; tld =\n'.com' or 'com'.\nPopulation: a curated per-market reference set — the local country TLD(s), .com, .info and a s"
},
{
"name": "search_visibility",
"description": "WHO OWNS SEARCH for a market's head hosting term — the customer-acquisition\nchannel view. A large host that is invisible here is leaving search to its competitors. It answers a\ndifferent question from market_structure's ownership view; compare them, do not substitute one.\nArguments: view = leaders (per group: best rank and page-one listings) | rankings (the folded page-one\nlist) | leads (ranked hosts we do not yet recognize as operators — coverage gaps and onboarding\nleads); market = ISO country code, any case.\nPopulation: page-one (top-ten) results for the market's head term, folded to brand "
},
{
"name": "pricing_profile",
"description": "The published offers of one named brand or consolidator group — the per-operator\nprice sheet behind a competitive-pricing question. One row per persistent product identity,\ncategory-labelled, each carrying its ladder rung (rung 1 = the entry offer, the cross-brand comparison\nunit — plan names are merchandising), entitlements, commitment and invoicing terms, and full economics\nin local currency, each figure marked as stated terms or estimate. Group queries add a posture per\nbrand and market.\nArguments: brand_or_group = the brand or consolidator; market='XX' for the full per-market set;\ncategory"
},
{
"name": "pricing_moves",
"description": "Whether an operator's prices actually moved, and what kind of move it was — the\ndated event feed behind a repricing or renewal-conduct question. Each event compares two consecutive\nobservations of the SAME persistent product; change_class says what moved (economics = a comparable\nprice, merchandising = promotional presentation only, observation = neither), and alert_grade is true\nonly for a confirmed economics event.\nArguments: brand_or_group and market narrow the feed to one operator or country; category narrows to\none product taxonomy — a market query otherwise mixes shared hosting,\ndomains "
},
{
"name": "email_security",
"description": "Email-authentication posture across a market or an operator's book — SPF and\nDMARC adoption and, more importantly, STRICTNESS: how much of the published policy actually rejects\nspoofed mail rather than merely monitoring it.\nArguments: market grain ('global', 'europe', or a European TLD) is open; operator-book grain is a\nnamed-provider feature.\nPopulation: the mail-carrying part of the active-domains book — every percentage is of the active domains\nthat carry mail, not of all websites. A count of policies published in the wrong place is reported\nseparately as a misconfiguration, never as adopti"
},
{
"name": "layer_stickiness",
"description": "How sticky each layer of the hosting stack ACTUALLY is — measured switching\nrates, for a churn-assumption or land-and-expand question. This is the proof behind \"front doors\nmigrate quickly, trust migrates slowly\".\nArguments: scope = 'global' or 'europe'; empty = both. chart=true returns a branded SVG.\nPopulation: the active-domains book over the trailing 26 weeks, annualized. A true\nprovider switch is distinguished from onboarding and lapse journeys, aftermarket rotation, a serving\nmove that left the customer relationship intact, and a provider's own address housekeeping — so the\nrate is not i"
},
{
"name": "saas_adoption",
"description": "Which SaaS categories an operator's customers have adopted — the attach-rate view\nfor an upsell, whitespace or book-quality question, per hosting book rather than per market.\nArguments: grain='group' (default) rolls up to the consolidator that owns the book; grain='operator'\ndrills to one nameserver book. operators = 1-3 comma-separated names to compare; a name with no book\nat the requested grain falls back to its group and the response says so. chart=true returns a branded\nSVG.\nPopulation: the MEASURED part of each book — the active domains of it we hold a page\nobservation for — published on "
},
{
"name": "technology_adoption",
"description": "What technology the European web runs on — CMS, e-commerce, analytics,\nmarketing, CRM, consent, support chat, security, anti-bot, backend, hosting, site builder, AI builder\nand AI API adoption, plus social presence — read from the page itself. Its neighbour header_adoption\nreads server response headers on a different population; vendor_adoption reads the DNS relationship\nlayer. The three are not additive.\nArguments: no category/provider/operator = adoption across every category published (free); naming\ncategory or provider = the per-provider breakdown (Pro; WordPress vs Wix vs Shopify). market"
},
{
"name": "header_adoption",
"description": "What INFRASTRUCTURE the European web runs on — CDN, origin cache, web server,\ncontrol panel, PaaS and runtime — read from the server's own response headers. Answers \"who runs\nVarnish, LiteSpeed, Plesk, IIS, OpenResty\" by operator, market or overall. Its neighbour\ntechnology_adoption reads the PAGE instead, on a different population: do not add or compare the two.\nArguments: no category/provider/operator = adoption across the categories (free); naming category or\nprovider = the per-provider breakdown (Pro). market = national-market TLD ('de','nl'); operator = an\noperator or consolidator book ('"
},
{
"name": "vendor_adoption",
"description": "WHO uses WHICH SaaS vendor, read from DNS rather than from the page — the\nrelationship layer complementing technology_adoption. Two mechanisms answer two different questions:\nmechanism='verification' = domain-verification records, evidence the relationship was ESTABLISHED;\nmechanism='spf_include' = which platform SENDS the domain's email.\nArguments: vendor = a name fragment ('openai','sendgrid'); mechanism = verification | spf_include;\nmarket = TLD ('de','nl'); top_n caps the rows; default = the all-markets rollup, most adopted first.\nPopulation: mechanism-specific and stated on every row — fo"
},
{
"name": "independent_operators",
"description": "List INDEPENDENT hosting operators - well-integrated and not owned by any consolidator the\nownership ledger maps - by size and market. A description of the independent segment, not a\nrecommendation.\nArguments: country_tld filters by the operator's dominant market; min_live sets the size floor and\nmax_results the page size.\nPopulation: independent operators above the infrastructure-cohesion floor, above the size floor, and\nnot owned by any consolidator the ownership ledger maps."
},
{
"name": "operator_profile",
"description": "Full profile of ONE hosting operator — footprint, geography, infrastructure\nsignature and cohesion, ownership check, book health and industry mix.\nArguments: brand_or_operator = an NS brand ('kasserver.com') or a provider id.\nPopulation: that operator's own book. For the packaged one-call decision-support view across all\nsections and its peers, use the dossier tool instead."
},
{
"name": "consolidator_scorecard",
"description": "Scorecard for ONE consolidator group (group.one, team.blue, your.online,\nunited_internet, ovhcloud…) — raw versus integrated book, integration quality, and the customer base's\nindustry mix, when the question is about one owner rather than the whole landscape.\nArguments: group = the consolidator, or a brand that resolves to one.\nPopulation: the group's folded book; each figure states the book it is measured on. For the whole\nmarket side by side, use consolidation_landscape."
},
{
"name": "book_health",
"description": "The quality of an operator's book, not its size: dead-page share, modern-email and SaaS-web\nadoption, geographic and industry concentration, plus tenure and churn.\nArguments: operator = a consumer BRAND, a nameserver operator, or a consolidator GROUP; brand names resolve\nautomatically (ionos to united_internet, domeneshop to miss_group) and prefer the group rollup, so a\nwhole consolidator's book health is one call. chart=true adds a branded book-composition SVG.\nPopulation: the named book; the 'grain' field on each row says whether it is a single operator book or\na folded group.\nMetric definit"
},
{
"name": "migration_flows",
"description": "Who is winning and losing customers against WHOM — direction-labelled migration\nflows involving a consolidator group, for a competitive-dynamics question. Movement WITHIN one\ngroup's own portfolio is group_movement's job, not this one's.\nArguments: subject = a consolidator group; layer = ns (the customer relationship) | host (the serving\nnetwork).\nPopulation: observed provider changes between the two dated readings. Magnitudes are DIRECTION-ONLY\nuntil the longitudinal panel calibrates them — read the direction, not the size."
},
{
"name": "peer_compare",
"description": "Side-by-side comparison of 2-6 named operators on footprint, book health and\nstability — for ranking a shortlist on one screen.\nArguments: operators = a list of 2-6 names; brands resolve to the group that owns them.\nPopulation: each operator's own book, each figure labelled with the book it is measured on so unlike\nbooks are not silently ranked against each other."
},
{
"name": "consolidation_landscape",
"description": "THE INDUSTRY MAP of hosting consolidation — every consolidator group side\nby side: live-business footprint, integration quality, sponsor and hold status, and acquisition\nactivity including the hosting-versus-software mix and latest deal. The one-call orientation on who is\nconsolidating the European hosting market and how well.\nArguments: none required.\nPopulation: the mapped consolidator groups; each row states the book its footprint is measured on, and\na measurement we do not stand behind for a given group is withheld with the reason attached rather\nthan served."
},
{
"name": "integration_depth",
"description": "HOW WELL a consolidator actually consolidates — the post-acquisition\nintegration question. No argument returns the scoreboard: what share of the\nportfolio sits on group platforms, and how deeply ledger-matched acquisitions were integrated (a low\nscore is a buy-and-hold FINDING, not an error).\nArguments: group = a consolidator or a brand that resolves to one, returns the per-brand breakdown with\nacquisition dates and two drill-down levels that must not be conflated — how much of each brand's book\nalready serves from the group backbone, and which machines serve it (a brand can be moved onto the\n"
},
{
"name": "dossier",
"description": "ONE-CALL DOSSIER on a hosting operator or consolidator group — the packaged\ndecision-support view when the question is \"brief me on this company\" rather than one metric:\nexecutive summary, market position, book quality, stability, SaaS attach, email-security posture,\nintegration status with the acquisition ledger, assembled risks and a peer table.\nArguments: target = a consumer brand ('ionos'), an operator ('domeneshop') or a group ('group.one');\ndetail='summary' (default: executive summary + risks), 'standard' or 'full'; or sections=\n'pricing,integration,…' for exactly those. meta.sections li"
},
{
"name": "coverage_calibration",
"description": "How complete HostingBrain's universe is — the honest answer to \"what share\nof the market do you actually see?\", calibrated against PUBLIC REGISTRY totals (Norid .no, SIDN .nl\nand similar), plus operator-level calibration examples.\nArguments: include_history=True returns the full dated series (the coverage trend); the default\nreturns the latest calibration per market and metric.\nPopulation: our observed web-provisioned population against officially registered totals for the same\nmarket.\nMethod: definitions(term='coverage_calibration')."
}
],
"profiled_at": "2026-09-24T23:00:50.022Z"
}
}