Provides tools for accessing Instagram data, supporting social media search and analysis of content and profiles.
Provides web search and AI-powered answer tools through Perplexity, enabling research and question-answering.
Provides tools for accessing Pinterest data, supporting social media search and analysis of pins, boards, and content.
Provides tools for accessing Reddit data, supporting social media search and analysis of posts, comments, and discussions.
Provides SEO tools powered by Semrush, enabling keyword research, competitive analysis, and search visibility insights.
Provides website traffic and audience analytics tools powered by Similarweb, enabling competitive and market research.
Provides tools for accessing YouTube data, supporting social media and video content search and analysis.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AIsa MCP Find the top SEO keywords for example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Every AIsa data API as MCP tools, behind one endpoint:
https://mcp.aisa.one/mcp580+ tools across 26 servers — SEO and AI visibility, finance, social, web search, sales and agent mail — reached through five meta tools, so the catalogue never has to land in a context window. Streamable HTTP. OAuth, with nothing to paste.
This repository holds @aisa-one/mcp, a small stdio bridge for clients that
cannot speak remote MCP yet. Most clients do not need it — give them the URL
above and stop reading at Connecting.
A client that lists 580 tools has spent its context before the first question. The root lists five:
Tool | What it does | Cost |
| Describe the task in plain words. Returns candidate operations with | Free |
| The categories a search can be narrowed to. | Free |
| One operation's full contract: arguments, response shape, whether it is read-only, price for your account, known pitfalls. | Free |
| Run one operation. | Per call |
| Up to 20 operations at once, under the same cap. | Per call |
Searching and reading schemas costs nothing, so an agent can survey the whole catalogue before spending anything.
Related MCP server: ads-mcp
One URL, transport streamable-http:
# Claude Code
claude mcp add --transport http -s user aisa https://mcp.aisa.one/mcp
# Codex
codex mcp add aisa --url https://mcp.aisa.one/mcpCursor, VS Code, Windsurf and the rest take the same URL as a url entry in
their MCP settings:
{
"mcpServers": {
"aisa": {
"type": "streamable_http",
"url": "https://mcp.aisa.one/mcp"
}
}
}Authorization is OAuth and needs no account to exist first. An unauthenticated
call answers 401 with a WWW-Authenticate header naming
https://mcp.aisa.one/.well-known/oauth-protected-resource/mcp (RFC 9728), and
the authorization server it points to accepts an unregistered client (RFC 7591)
— so the client registers itself, opens a browser, and you click Allow once.
That 401 is the discovery mechanism, not a failure.
Already have a key from console.aisa.one? Send it as
Authorization: Bearer $AISA_API_KEY and no browser opens. That is the way in
over SSH or in CI.
Claude Desktop and a few others spawn a local command and talk over stdin and stdout. This package is that command:
{
"mcpServers": {
"aisa": {
"command": "npx",
"args": ["-y", "@aisa-one/mcp"]
}
}
}It bridges stdio to the remote endpoint, runs the OAuth browser flow on first
use and caches the token. The bridging itself is
mcp-remote's; this package supplies
the endpoint, the header form and the transport flag so you do not have to.
npx -y @aisa-one/mcp # the root: five tools, reaches everything
npx -y @aisa-one/mcp seo # one category, its tools listed directly
npx -y @aisa-one/mcp apollo # one provider and nothing else
npx -y @aisa-one/mcp --helpAISA_API_KEY is picked up from the environment when it is set. Any further
arguments are passed to mcp-remote unchanged.
Every path below is the same root pinned to a different slice, so each still
carries the five meta tools, the price cap and search over everything. Pinning
changes what tools/list returns, never what is reachable.
Endpoint | Listed | Reachable | Providers |
| 5 meta tools | everything | 26 |
| 43 | 163 | Apollo, Similarweb, X, Instagram, Reddit, Pinterest, YouTube, creator discovery |
| 60 | 316 | DataForSEO, Semrush, Ahrefs |
| 79 | 79 | Apollo, Similarweb, creator discovery |
| 56 | 56 | X, Instagram, Reddit, Pinterest, YouTube |
| 48 | 48 | market data, crypto, prediction markets |
| 30 | 30 | Tavily, Exa, Perplexity, Firecrawl, Oxylabs |
| one provider | — | 26 of them |
Counts move as the catalogue does. The live ones, and every provider endpoint,
are at mcp.aisa.one/servers, generated per
request by the running service.
search, get_details and list_categories are free. use and batch_use
are billed per call at the same prices as the AIsa REST API, with no seat and no
monthly minimum for the MCP itself. Every call takes max_price_usd, and one
that would cost more is refused before any charge.
A 402 says which of two things is missing — balance, or the Hive GTM Growth subscription — and where to get it. Prices are at aisa.one/pricing.
mcp.aisa.one/llms.txt — the whole server
described for an agent, rendered live from its own catalogue
mcp.aisa.one/servers — the live inventory:
entry points, modules, per-provider endpoints, tool counts
mcp.aisa.one/.well-known/mcp/server-card.json
— the root's server card
aisa.one/mcp — the same material for a person
Published in the official MCP Registry under the one.aisa namespace: the
root as one.aisa/mcp, plus one entry per category and per provider
MIT
Execute up to 20 operations concurrently (tool-router's batch_use). Each item answers independently; one failure never cancels the others. Billed per call to your AIsa key.
| Name | Required | Description | Default |
|---|---|---|---|
| calls | Yes | Up to 20 items of {call_id, operation_id, arguments}; steps at the same execution_level of a plan go in one batch | |
| search_id | No | search_id from the search that found these operations | |
| max_price_usd | No | Per-call price cap applied to every item |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so safety is covered. The description adds valuable behavior: independence of items (one failure doesn't cancel others) and per-call billing. These are not derivable from annotations and help the agent set expectations.
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 short sentences with zero filler. The action and limit are front-loaded. The phrase 'tool-router's batch_use' is redundant since it restates the tool name, but it's a minor flaw. Overall it is concise and well-structured.
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?
With annotations covering destructive behavior and an output schema presumably describing results, the description covers the key operational aspects: concurrency limit, independence, and billing. It doesn't mention error reporting formats, but those likely live in the output schema. It is sufficiently complete for a batch 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 description coverage is 100%, so the schema fully documents each parameter. The description adds no parameter-specific details. The calls parameter's description already explains the structure and batching context, so the baseline of 3 applies; the description doesn't need to compensate.
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 states a clear action (execute) and resource (operations) with a concrete limit (up to 20) and concurrency. It doesn't explicitly name the sibling 'use' for single operations, but the distinction is clear enough from the concurrency and limit. The redundancy of 'tool-router's batch_use' is minor.
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 gives no guidance on when to use this tool versus the sibling 'use' tool. The schema note about 'steps at the same execution_level of a plan go in one batch' is helpful, but it lives in the schema, not the description. The description only implies batching via concurrency but doesn't state when to choose it over the single-operation alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full contract of one or more operations: arguments_schema, response_schema, read_only, side_effects, availability, price, suggested_max_price_usd and known_pitfalls. Free — a quote authenticates like a call but stops before any spend.
price.model distinguishes the sources: quoted is what this
account would be charged now, list is the published price,
dynamic means the price varies with the request and only a quote
states it, composed means the operation runs several upstream
calls. suggested_max_price_usd is that estimate with headroom,
in the shape use and batch_use take as max_price_usd.
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | No | The arguments the operation would be called with, for a price that reflects them. Keyed by operation_id for a batch, or passed flat for a single operation_id. Routes whose required parameters are validated before pricing have no price without them. | |
| with_quote | No | Whether each operation is priced for this account before the answer. One round trip per operation; spends nothing. | |
| operation_id | No | One operation_id from search | |
| operation_ids | No | Up to 20 operation_ids, for a batch |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: it is free, stops before any spend, and explains how price.model varies (quoted, list, dynamic, composed). It also clarifies that suggested_max_price_usd has headroom. This goes beyond the annotation flags and gives the agent a clear model of what happens.
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 moderately long but well structured: it opens with the core purpose, then explains the price model in a dedicated paragraph. No redundancy or filler. It front-loads the most critical information (contract fields) and then gives necessary detail about price semantics. Slightly dense but 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?
The tool has an output schema, so return values need no description. The description covers the key behavioral aspects (no spend, pricing models, max_price headroom) and clarifies edge cases like routes without a price. For a read-only informational tool, this is complete enough for an agent to use it correctly.
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 description coverage is 100%, so parameters are already documented. The description adds some nuance, such as how arguments affect pricing and that required parameters may be needed before a price can be quoted. It also clarifies with_quote's purpose (one round trip, spends nothing). These are useful but not essential given the schema's completeness.
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 states a specific purpose: returning the full contract of one or more operations, including schemas, read_only, side_effects, price, and known_pitfalls. It clearly distinguishes this from executing operations (use, batch_use) and from discovery (search, list_categories). The verb 'get' and the noun 'details' align with the title, and the first sentence is explicit.
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 implies the tool is used to assess an operation before spending (e.g., 'A quote authenticates like a call but stops before any spend'), and the schema says 'One operation_id from search', hinting at a flow. However, it never explicitly states when to choose this over siblings like use or search, nor does it give exclusions. The guidance is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The AIsa catalogue at a glance: categories, the servers in each, tool counts, and the dedicated endpoint to connect if you only need one category. Free; no key needed. (AIsa-only: tool-router has no equivalent.)
Use mcp.aisa.one/mcp?modules=<category> (or mcp.aisa.one/<category>/mcp)
to have that category's tools listed directly instead of via search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: the tool is free, requires no key, and can direct users to a category-specific endpoint that lists tools directly rather than through search.
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 moderately detailed but every sentence adds useful information: output scope, cost/auth, sibling differentiation, and endpoint usage. It is slightly longer than strictly necessary but remains well-structured and front-loaded with the core 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?
For a zero-parameter, read-only tool with an output schema and safety annotations, the description is complete. It covers what the tool returns, the free/no-key access model, and provides the category endpoint for specialized use, leaving no essential gap for an agent to call it correctly.
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, so the baseline is 4. The description includes a <category> placeholder only in the endpoint examples, not as a tool parameter, which is appropriate supplementary guidance rather than a parameter-semantics gap.
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 what the tool does: it presents the AIsa catalogue at a glance, including categories, servers, tool counts, and a dedicated category endpoint. It also distinguishes itself from search by explaining that the endpoint lists tools directly instead of via search.
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 usage context: use list_categories for a catalogue overview, and use the provided endpoint when you only need one category. It explicitly contrasts with search ('instead of via search') and notes tool-router has no equivalent, although it does not exhaustively cover all sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find AIsa data operations across SEO & AI visibility, finance, social, web search & research, sales and agent mail — 950+ APIs — by describing the task. Free; no key needed.
Returns tool-router's SearchResponse: retrieval_mode (plan |
endpoint | clarification), an optional plan, and candidates with
operation_id, provider, method, path, summary, required_inputs,
price, match_reasons and details_ref — plus input_schema, so a
candidate can be passed to use without calling get_details, and
modules, the entry points that pin it.
Search spans the full AIsa catalogue, not only the category pinned
on this endpoint, so an operation is discoverable here even when it
is not in the current tools/list; a candidate whose modules does
not include the current one still runs. When more than one provider
offers the same metric, the candidates make that visible.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum candidates, 1-10 | |
| query | Yes | What you need, in plain language, e.g. 'backlinks of a domain', 'recent tweets by a user', 'insider trades for AAPL'. English works best. | |
| category | No | Restrict to one category (seo, finance, social, search, sales, mail). Omit to search everything. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavior beyond annotations: search spans the entire AIsa catalogue, candidates may belong to modules other than the current one, multiple providers for the same metric are surfaced, and no API key is required. This gives the agent a clear picture of scope and output behavior.
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 the core purpose and is dense with useful information: scope, no-auth requirement, response shape, and relationship to the catalogue. Each sentence adds operational value, and the structure makes the tool's behavior predictable.
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 complex discovery tool with output schema, the description is unusually complete: it explains the response modalities, candidate fields, direct pass-through to `use`, full-catalogue search behavior, and cross-provider visibility. An agent has enough context to invoke and interpret the tool correctly.
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 the schema already documents all parameters. The description adds value by explaining that the category parameter is not a hard boundary—search spans the full catalogue—and that queries are plain-language task descriptions, which clarifies how to use the tool effectively.
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 finds AIsa data operations across many categories via a plain-language query. It distinguishes itself from siblings like get_details and use by emphasizing that search covers the full catalogue, not just the pinned category.
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 conveys when to use search: when you need to discover operations across the full catalogue, even those not in the current tools/list. It also implicitly contrasts with get_details by noting that returned candidates already include input_schema, so they can be passed directly to `use` without an extra call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one AIsa operation. Billed per call to your AIsa key.
Answers in tool-router's BatchCallResult shape: successful, data or error {type, status, message, retryable}. Pinned tools in tools/list can also be called directly; this is the way to call anything found through search.
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | No | Arguments matching input_schema / arguments_schema | |
| search_id | No | search_id from the search that found this operation | |
| operation_id | Yes | operation_id as returned by search | |
| max_price_usd | No | Refuse the call before any spend if it would cost more than this many USD |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly=false, openWorldHint=true, and destructiveHint=true. The description adds valuable behavior beyond that: billing per call, the BatchCallResult response shape, and the error structure with retryable status. It does not spell out side effects, but the destructive flag is already carried by annotations, so the additional context 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 short sentences, each earning its place: purpose, cost, response shape, and routing guidance. Key behavioral facts are front-loaded, and nothing is redundant with the schema or annotations.
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 that an output schema exists and all parameters have descriptions, the tool description is complete enough for correct invocation. It covers cost, return/error contracts, and how routing to this tool differs from calling pinned tools directly, leaving no practical gap.
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 description coverage is 100%, and each parameter is already clearly documented: operation_id as returned by search, search_id provenance, arguments matching input_schema, and max_price_usd as a spend guard. The description does not need to add parameter detail, so baseline 3 is appropriate.
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 opens with 'Execute one AIsa operation,' a specific verb+resource statement. The word 'one' distinguishes it from the sibling batch_use, and the closing note distinguishes it from calling pinned tools directly. An agent can tell what this tool is for immediately.
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 states when to use the tool: 'this is the way to call anything found through search.' It also gives the alternative: 'Pinned tools in tools/list can also be called directly.' This is clear when-versus-alternative guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0batch_useget_detailslist_categoriessearchuseScored across 5 tools
Each tool has a clearly distinct role: list_categories covers category-level discovery, search finds operations by task, get_details exposes contracts, and use/batch_use execute single or batched operations. There is no meaningful overlap between any pair.
Names are all lowercase imperative commands with underscores, and the pair use/batch_use is logical. The main inconsistency is that search and use are bare verbs while list_categories and get_details include a noun object, but the pattern remains predictable and readable.
Five tools is well-scoped for a gateway server that fronts a huge catalogue: two discovery tools, one detail tool, and two execution tools. Every tool earns its place and the count is appropriate.
The server covers the full lifecycle of working with the AIsa catalogue: browse categories, search operations, inspect contracts, execute one operation, and execute many operations. No obvious dead ends or missing capabilities for the stated purpose.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Your agent needs live data — a competitor's traffic, who to contact there, what people are saying, what Google and ChatGPT answer about you, a company's filings. Normally that is six vendor accounts, six sets of keys and six SDKs. This is one URL. **What you can ask for** • "How much traffic does stripe.com get, where does it come from, and who competes for the same keywords?" • "Find 20 Series-B fintech companies in Germany and the heads of marketing there, with emails." • "Does ChatGPT mention our brand when someone asks for the best CRM — and what does it cite?" • "What is X saying about $NVDA today, and what did the stock actually do?" • "Search the web for this, then scrape the three best pages into markdown." **How to use it** Point any MCP client at https://mcp.aisa.one/mcp and sign in with OAuth — there is no key to create or paste. Then just ask: the agent calls search to find the right operation and use to run it. **Why this rather than the source** 26 sources behind one account and one bill — DataForSEO, Semrush, Ahrefs, Similarweb, Apollo, X/Twitter, Instagram, Reddit, Pinterest, YouTube, Tavily, Exa, Perplexity, Firecrawl, CoinGecko, Kalshi, Polymarket, AgentMail and more, 580+ operations. tools/list returns five tools, not 580, so the introduction does not eat your context window. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** One slice at a time: https://mcp.aisa.one/seo/mcp · /finance/mcp · /social/mcp · /search/mcp · /sales/mcp · /mail/mcp · /gtm/mcp, or a single provider like /twitter-api/mcp. Same account, fewer tools listed, and search still reaches everything. Full list at https://mcp.aisa.one/servers
Search, document and execute authenticated API calls across 700+ apps via one MCP server
