Your agent needs Akta Pro: resolve a company, pull its profile, track its news, maybe build a target list. Akta ships a hosted Model Context Protocol (MCP) server alongside its REST API, and both are official. They are not interchangeable. They differ in which endpoints exist, how company identity gets resolved, what each payload costs in tokens and credits, and how much plan-tier logic lands in your code. Here's how to pick between Akta Pro MCP and the Akta Pro API.
Both interfaces sit on the same dataset from Akta, a Wokelo AI product: company profiles, entity-resolved news, and alternative signals such as headcount and web traffic. What differs is the surface your agent talks to.
Akta hosts the MCP server itself as a remote endpoint over Streamable HTTP, so there is nothing to run locally. It launched on July 23, 2026, is available to all users, and, according to Akta's changelog, calls the same REST API underneath. Auth depends on the client: native connector auth in Claude's web and desktop apps, OAuth in ChatGPT, and an x-api-key header everywhere else, including Cursor, VS Code, and Claude Code.
The server exposes 17 synchronous tools. Only company_data returns Markdown; the rest return JSON. Setup steps live in the Akta Pro MCP server setup guide.
The REST API covers news signals, company data billed per section, list generation, six alternative-signal endpoints (headcount, web traffic, job posts, social posts, employee reviews, product reviews), and supporting endpoints for company search, industry search, company addition, request status, and filter building. Every request carries an API key in the x-api-key header. Each Akta account creates its own keys in Akta's playground, and a key is shown only once.
Billing is in credits: $0.05 per credit on pay-as-you-go, $0.04 on Subscription, and custom pricing on Enterprise. The reference lives in the Akta Pro API documentation.
Four dimensions decide this for an Akta Pro agent: what it can call, how it authenticates, what you operate in production, and which workload you are actually building.
MCP covers the research loop. The REST API owns asynchronous and pipeline work.
The gaps cluster around two things the MCP server deliberately avoids: asynchronous work and implicit entity resolution. Every MCP tool is synchronous, so Company Addition, which queues a missing company and reports completion through polling or a webhook, has no MCP equivalent. When an MCP agent can't resolve a company, the tool descriptions tell it to say the company isn't covered rather than guess. A pipeline on the REST API can submit the company instead, on Subscription and Enterprise plans.
Filter Builder is REST-only too. It turns a plain-language description into a structured filters object for 2.5 credits per run. On MCP, the agent assembles filters itself from the free list_filters and get_filter_values tools.
MCP bakes Akta's usage protocol into its tool descriptions. company_search is free and effectively mandatory, because every other company tool rejects names and websites and accepts only the UUID it returns. That looks like friction until one domain maps to several entities; the descriptions cite stripe.com resolving to Stripe, Stripe Capital, and Stripe Atlas. The REST API accepts a website directly and quietly makes that disambiguation call for you.
Payloads follow the same design. company_data requires an explicit section list, and news_signals stays compact while news_detail fetches article bodies on demand. The REST news endpoint returns full_text on every article, so a direct-API agent needs a low limit or a stripping step.
On the MCP path, auth depends on the client. Claude's web and desktop apps use native connector auth, ChatGPT runs OAuth, and every other client sends an API key in the x-api-key header. Akta documents OAuth only for ChatGPT, so a production agent you host should plan on the key.
The REST API is simpler still: every endpoint takes the same x-api-key header, and there is no OAuth grant to delegate. On either path, each end user brings their own Akta key, created in their own account and shown to them once.
This is the Akta-specific twist. Every key resolves to a plan tier, and the tier decides what the tools return. Alternative-signal endpoints return 403 below Subscription on both paths. On MCP, Enterprise-only company_data sections are skipped silently, with a note in the Markdown. Documented rate limits are per plan: pay-as-you-go allows 25 requests per minute, 100 company searches per day, and 100 Company Data calls per month.
So per-user keys mean per-user capability surfaces, and the same agent behaves differently for two users on different plans. Shared keys are worse, because every user draws on one quota and one credit balance. Both paths require per-user credential isolation, and neither stores, rotates, or revokes keys for you.
On MCP, Akta owns the tool schemas, the Markdown rendering, and the resolve-first protocol. You own key storage, plan awareness per user, and credit spend, because the model decides which paid tools to call. Two failure modes are silent. An invented filter value matches zero companies instead of erroring, and a dropped value broadens a list without failing. The tool descriptions tell the agent to read warnings; your code should enforce it.
Capacity follows the key, not the interface. Akta's rate-limit table counts the Markdown and concise variants of Company Data against the same cap as the JSON endpoint, and those are the formats the MCP tools return.
On the API, you own everything: parameter construction, pagination, retries when a rate limit trips, payload trimming, and the section list. The defaults are expensive. Omit sections on Company Data and the API returns every section your plan allows, billed per section. The 14 standard sections add up to about 17 credits per company, roughly $0.85 on pay-as-you-go, against a flat 8 credits for the MCP server's company_data_concise.
MCP schemas change when the provider changes the server, and Akta's are moving. Akta's MCP docs describe generate_company_list as accepting structured filters or a natural-language query, with optional per-company enrichment. The schema published on the Scalekit connector page takes filters only, requires at least one, and returns identity fields per company with no enrichment option. Build against the tools/list response your client receives, not a docs summary. On Claude's MCP connector, the mcp-client-2026-09-15 beta can pin a server's tool list for a conversation.
REST changes arrive as dated changelog entries instead. The July 9, 2026 News release, for example, switched industry to resolved codes, a breaking change. For a broader look at MCP vs. direct API tradeoffs, see MCP is up to 32× more expensive than CLI. Here's why we still use it.
The split follows the workload, not the data. Use Akta Pro MCP when:
Use the Akta Pro API directly when:
Pick either path and you still hold one Akta key per user. Neither path gives you a vault, rotation, or revocation.
In a multi-tenant agent, every end user connects their own Akta account. That is N keys to store encrypted, N plan tiers to track, and N credit balances that can run dry mid-task. Keys are shown once at creation, so a key lost from your store means asking the user for a new one. Offboarding is on you too: when a customer leaves, their key has to come out of wherever your agent kept it. The credential type is the same on both paths, and so is the infrastructure problem.
The shortcut is tempting. You put one Subscription key in an environment variable, ship a research agent to five customer teams, and the demo works. A month later, one team starts a bulk enrichment job, the key hits its plan's per-minute limit, and every other team's agent starts failing mid-task. Nobody can say which customer spent the credits, because every call came from one account. Shared credentials are a single-user solution. They do not survive a second user. For a deeper look at why static credentials fail at scale, see OAuth vs API keys for AI agents.
Scalekit's Akta Pro connectors collect each user's key through a hosted form, keep it in an encrypted per-tenant vault, and inject it at call time on both the MCP and API paths, so the path decision doesn't change your credential infrastructure.
The build below uses Python, the Scalekit SDK, and Claude through the Anthropic SDK. It covers both paths: the aktapro API connector in a tool-use loop, and the aktapromcp connector behind a Virtual MCP server. Scalekit's docs show the same pattern for LangChain, Google ADK, CrewAI, and Mastra, starting from the Anthropic integration guide.
Create the Akta Pro and Akta Pro MCP connections in the Scalekit dashboard under AgentKit > Connections, and copy your credentials from Developers > API Credentials. The code uses the connection names from the connector docs, aktapro and aktapromcp. Every connection_name must match the dashboard exactly; a mismatch is the most common integration error. The two connectors are separate connections, so a user who uses both connects a key to each.
A connected account is the per-user record that holds the key. For an API-key connector like Akta Pro, get_authorization_link returns a link to a Scalekit-hosted form where the user pastes their own key, so the key never passes through your agent code or the model's context.
In production, replace input() with your own UI flow, and subscribe to the connected_account.status_updated webhook to catch accounts that leave ACTIVE.
The agent does not load a connector catalog. list_scoped_tools returns only the tools this user's connected account is authorized to call, filtered here to the aktapro connection. For the API connector, that surface is a single tool, aktapro_search_news, whose 23 parameters map one to one onto the REST News Signals endpoint's query parameters. Understanding agent tool calling auth patterns will help you structure this loop correctly for production.
Execution happens in the loop. Claude picks the tool and its arguments; execute_tool resolves the user's key server-side and calls Akta.
Each execute_tool call returns an execution_id and lands in AgentKit's tool call log under this user's identifier.
A Virtual MCP server is a scoped endpoint: you declare which connections and tools it exposes, once per agent role, and get back a static URL. Continuing the same script, this definition exposes 7 of the 17 Akta tools: four free lookup tools, the two news tools, and the flat-rate concise profile. Per-section company_data, list generation, and the Subscription-only signal tools stay off this agent's surface.
Before each run, confirm the user's connections are active, then mint a short-lived session token bound to that user. The Virtual MCP setup guide also covers listing, updating, and deleting servers.
Anthropic's API calls the Virtual MCP server directly, so there is no loop to write. Tokens default to about an hour, and a host holding an expired token fails at its next tool call, not at startup, so mint one per run. Scalekit's Node SDK doesn't mint session tokens yet; TypeScript agents mint them on a Python backend.
The aktapro connector ships one prebuilt tool, but the connected account works for the rest of the REST API too. actions.request proxies a call to a provider path and injects the user's key server-side, which is how a pipeline reaches Company Data, List Generation, or Company Addition without holding raw keys. Wrap each endpoint in a tool contract shaped around your agent's intent; the custom tools guide shows the pattern.
Credential custody is the baseline AgentKit covers. Two capabilities matter more once an Akta Pro agent reaches real users.
AgentKit writes every tool call to a tool call log with its timestamp, connection, tool name, user identifier, latency, and error details. The identifier is the end user who triggered the call, not the agent process. Failures are split by origin, so an inactive connected account reads differently from an Akta-side error, and per-connector success rates flag a degrading connector before users do. For Akta, that answers what a shared key can't: which user spent the credits, which calls hit a plan wall, and whose run failed overnight. Scalekit's Akta Pro connector page cites 90 days of call history, exportable to a SIEM. More on agent tool observability and how to keep every action traceable in production.
Akta is rarely the only tool. A diligence agent pairs it with a CRM, and a news agent posts to Slack. One Virtual MCP server can map tools from several connections, so the agent gets one endpoint and one token instead of an MCP client per vendor. Scoping matters more than usual here, because Akta's tool descriptions carry its whole usage protocol: generate_company_list alone runs past 300 words. At roughly 200 tokens per tool, a 40-tool server burns about 8,000 tokens before the agent does any work, and scoping to 5 to 10 tools cuts that by 80%. Scope caps spend too: an agent that can't see per-section company_data can't bill 17 credits per company.
One server definition serves every tenant. Before each run you mint a session token bound to one user's connected accounts, so tenant A's run resolves tenant A's key and spends tenant A's credits, never tenant B's. Because Akta keys carry plan tiers, you can also define one server per role and plan: a pay-as-you-go research agent without the six Subscription-only tools, and a Subscription variant with them. The endpoint is static; the identity is per user. What a user's plan can't do, their agent never sees. For the broader pattern, see access control for multi-tenant AI agents.
If you are building a GTM or research agent around Akta, these templates cover the surrounding workflow: the competitive intelligence briefing agent, the sales call prep agent, the outbound prospecting agent, and the deal intelligence agent. AgentKit plans are on the Scalekit pricing page.
Recommended reading: the Apollo MCP vs Apollo API and ZoomInfo MCP vs ZoomInfo API breakdowns cover the same decision for adjacent company-data tools.
If your Akta Pro agent is interactive, an analyst in Claude Code or a chat assistant researching companies and triaging news, build against the MCP server. Its resolve-first tools and compact payloads are designed for a model to drive. If your agent is a pipeline that enriches records keyed by website, needs JSON, or must add companies Akta doesn't cover yet, build against the REST API and wrap the endpoints you need.
Either way, you are managing one Akta key per user, and every key is also a plan and a credit balance. That is the part that needs production-grade infrastructure. For teams navigating the same credential challenges across many tool providers, credential ownership patterns for agent tool calling covers the design tradeoffs in depth.
Building an Akta Pro agent for multiple customers? Talk to us for immediate help with connected accounts, Virtual MCP design, and plan-aware tool scoping.
Browse the Akta Pro connector for AI agents, the Akta Pro API connector docs, the Akta Pro MCP connector docs, or all Scalekit connectors.
