Skip to main content
Company data is complex: dozens of countries and US states, each with its own registers, identifiers, modes, and data quirks. The Topograph MCP plugs into your AI coding agent — Claude Code, Cursor, or any MCP-aware editor — so it pulls live coverage, pricing, and integration methodology on demand. Ask questions in plain English. Get grounded answers. Ship your integration in an afternoon.
Two commands and you’re in. In Claude Code:
Sign in with Topograph the first time; the MCP runs against https://api.topograph.co/designer-mcp from there.

​
What you can ask

These prompts work today and call the right tools and rules under the hood:
Sample prompts
Each answer is grounded in live data from the Topograph catalog and the canonical integration rules — not from training data that may be months out of date.

​
Why it’s better than reading docs

Live country catalog

Coverage, identifiers, datapoints, legal forms, roles, and pricing are pulled live from the catalog. You’ll never get an answer based on stale documentation.

Methodology built in

The MCP ships with the canonical patterns: search-first identifier resolution, onboarding vs verification phasing, webhook terminal detection, budget caps, and more.

Code that compiles

Example snippets are derived from the OpenAPI spec. No hallucinated endpoint paths, no fabricated request shapes.

Grounded in your editor

Your agent works alongside your existing code — pull data, write the integration, run it, iterate. No copy-pasting from a docs tab.

​
Country-specific integration data

Call get_country with the country code (for example, {"cc":"FR"}) to retrieve its public manifest. The same manifest is available through the topograph://countries/FR resource. Use it when mapping a country into your own model; use get_openapi with path: "/v2/company" and includeSchemas: true for the company API response schema. Country-specific manifest fields include:
  • identifiers: accepted identifiers, their formats and examples, whether they are primary or searchable, and the matching company.identifiers response key when Topograph returns one.
  • activityCodes: responseKeys lists revision-specific company.activities keys with their versions, isLatest, and supersedes. unversionedKeys lists keys whose revision is unknown, with a reason. Legacy aliases are not enumerated here.
  • enums: maintained country enum sets: legalForms, legalFormsOnboarding, roles, companyStatuses, registerCourts (local courts or offices), and registerTypes (register sections).
  • complianceSignals: register-reported compliance flags and statutory-filing fields available for the country.
  • registers and dataBlocks: public register descriptions, supported datapoints, entity types, modes, and their applicability notes.
  • countryDocuments: document types and names, including subType and appliesTo where supplied. subType matches the response item’s subType. otherDocuments lists additional document names and descriptions.
  • developmentStatus and availableOnRequest: integration maturity and capabilities available on request, where listed.
  • performance: indicative search, datapoint, and document timings. Datapoint timings describe source speed, not end-to-end request turnaround.
Each enum set contains values and sources. Legal forms and roles include code, source (the code system), localName, standardized, and optionally englishName. Legal forms may include iso20275Code and isDiscontinued. Roles include isLegalRepresentative and isOtherKeyPerson, and may include iso5009Mappings with oorCode, elfCode, and optional legalBasis. A role can have several ISO mappings depending on the legal form; match elfCode to the legal form’s iso20275Code where available. companyStatuses.values contains strings. registerCourts.values contains localName, which can form part of a registration identifier. registerTypes.values contains code, localName, and optionally englishName and scope. Identifier appliesTo and activityCodes.local[].appliesTo describe the entity types to which an entry applies; when omitted, the entry applies to all covered entity types. In complianceSignals, flags.values[].kind identifies a company.complianceFlags entry. reportsNegative: true means the register can explicitly report active: false; absence is not the same as a negative result. statutoryFilings.values[].kind identifies an entry in company.statutoryFilings, and fields lists relative paths such as lastFiled.filedOn. Optional cadence and note explain its filing cycle and limitations. Data-block modes describe fast, authoritative, datapoint subsets, caveats, and routing notes. Their source references identify entries in registers; consult per-datapoint details and routings as well as defaults. A cached flag describes a non-authoritative cached mode, not a freshness guarantee. A block’s requiredCredential identifies the public register credential sourceKey and whether it is mandatory for that fetch or enhances completeness. See register credentials for setup and fallback behavior. legalForms describes verification values. When legalFormsOnboarding is absent, use legalForms for all modes. When present, it supplies the onboarding-specific values. Read the provenance in sources for scope and completeness: some sets contain observed values rather than an exhaustive closed list.
An absent optional field does not by itself prove the underlying company data is unavailable. For example, an identifier without key may be accepted for lookup but not echoed in company.identifiers. Consult the field-specific meaning and country coverage. list_countries only returns summaries, and find_data does not search enum values or identifier keys; use get_country for these mappings.

​
When the MCP earns its keep

Use it when you would otherwise be context-switching to docs:
  • Onboarding a country you’ve never integrated before
  • Sizing volume against country coverage and capability
  • Designing async delivery (webhooks vs polling, terminal-event detection)
  • Picking the right datapoint mix for KYB vs onboarding flows
  • Debugging “why am I getting this error / why is this datapoint missing?”
  • Reviewing an existing integration against the canonical methodology
  • Writing tests against a development environment (or the deprecated TEST country)
For one-off questions, the regular docs are still the right tool. For real integration work, the MCP is faster.

​
What’s inside

Tools your agent will call:
  • list_countries, get_country, find_data — live country and capability catalog.
  • get_pricing — public per-country prices for any data block.
  • search_docs, get_doc — search and fetch documentation pages.
  • get_openapi — endpoint definitions straight from the OpenAPI spec.
  • example_snippet — copy-paste snippets in curl, Node, Python, or Go.
  • whoami, my_pricing_simulations, personalized_quote — pricing simulator quotes tied to your Topograph login.
Built-in integration rules your agent reads:
  • Onboarding methodology — the five-step KYB flow from search to audit.
  • Search-first resolution — turning fuzzy user input into a canonical company ID.
  • Onboarding vs verification mode — picking the right one per call.
  • Webhooks — signed delivery, progressive payloads, terminal-event detection.
  • Workspaces — required for resellers, end-client attribution and rebilling.
  • Budgets — maxBudget, profileMaxBudget, graphMaxBudget.
  • TEST country (deprecated): magic identifiers for deterministic testing.
  • Data blocks, documents, common pitfalls, and country coverage matrix.

​
Install: other clients

If your client supports HTTP MCP servers and OAuth discovery, point it at the endpoint directly:
Your client will prompt you to sign in with Topograph the first time it queries the MCP. No REST API key is required for the MCP itself; it’s a separate authentication tied to your Topograph login.

​
Public repository

The plugin is published from the public marketplace repository: github.com/getsemaphore/topograph-mcp-library The source is mirrored from Topograph’s monorepo on every release.