Your agent needs creators who actually fit — starting from one profile you already like, or from a brief — and then a way to reach them.
What you can ask for • "Find creators similar to this profile, in this country." • "Who else makes content like this account, with a comparable audience?" • "Look up the contact email for this creator." • "Build a shortlist for this brief and give me the emails."
How to use it Point any MCP client at https://mcp.aisa.one/creator-discovery/mcp and sign in with OAuth — there is no key to create or paste. 2 tools: similar-creator lookup from a seed profile or a brief, and an email lookup for a creator.
Why this rather than the source Similarity from a profile you already trust, rather than a filter over a follower-count database.
It is also a door to the rest The same login reaches 26 sources and 580+ operations. Shortlist the creators here, then ask the same agent for their posting history on Instagram or X — without adding a second server.
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 https://mcp.aisa.one/social/mcp for what those creators actually post; https://mcp.aisa.one/sales/mcp for the rest of the outreach.
Scored across 8 tools
Most tools are clearly distinct: search/list_categories are discovery, use/batch_use are execution (single vs bulk), and the three waveinflu tools target different creator tasks. Minor overlap exists between search and list_categories (both discovery) and between use and batch_use, but descriptions make the boundaries clear.
Generic router tools use a clean verb_noun snake_case pattern (search, use, batch_use, get_details, list_categories), but the waveinflu tools introduce an HTTP-method prefix with provider name (post_waveinflu_*). The two families are internally consistent but mixed as a set.
Eight tools is well-scoped: five generic router/catalogue operations plus three purpose-built creator-discovery tools. No redundant or filler tools.
Creator discovery covers natural-language search, similarity search, and email lookup, with a generic router (search/use/batch_use/get_details) to reach the broader AIsa catalogue. There is no direct single-creator get-by-ID, but the search/similar surfaces largely cover that workflow.
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.
Finds creators from a natural-language brief instead of a seed account. platform and query are required; add limit (1–100, default 40) and the same optional filters as Similar Creators. Describe the creators you want in plain language (for example, "beauty creators in the US") and the response returns matching creators in the same rich shape as Similar Creators — full profile metrics plus AI-inferred gender, ageRange, ethnicity, faceVisibility, accountPositioning, aiDescription, and a relevance score. Billing is per delivered creator (data.count).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of creators to return. Default 40, range 1–100. Caps the billed count. | |
| query | Yes | Natural-language description of the creators you are looking for. | |
| filters | No | Optional filters applied before matching. All fields are optional. | |
| platform | Yes | Target platform. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, which would otherwise be puzzling for a search; the description resolves this by disclosing 'Billing is per delivered creator (data.count),' giving concrete cost semantics beyond the annotations. It still omits rate limits or pagination behavior, so it is not exhaustive.
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-loads the core distinction and then packs required params, limit bounds, return shape, and billing into a compact block with no filler. It is dense but every clause carries an operational fact, with only minor repetition of the limit range.
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 an output schema exists, the description needn't detail return fields, yet it still names the AI-inferred attributes and relevance score, and it covers billing, required params, and filters. Nothing critical is missing, though pagination/ordering behavior is not addressed.
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 all four parameters and the nested filters object are already documented. The description adds the limit range/default and the 'same optional filters as Similar Creators' cross-reference, but repeats schema content rather than adding format or edge-case meaning, matching the baseline 3.
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?
States a specific verb+resource ('Finds creators') and immediately distinguishes the mechanism from its sibling: 'from a natural-language brief instead of a seed account,' directly contrasting with post_waveinflu_similar_creators. An agent can tell the two apart without opening either schema.
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 'instead of a seed account' framing implies the selection condition — use this when you have a text brief rather than a seed creator — and explicitly points at the parameters to supply. It stops short of an explicit 'if you have a seed account, use Similar Creators' exclusion, so routing still requires slight inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up the contact email for one Instagram, TikTok, or YouTube creator from a profile URL. Pass profile_url; the response returns the parsed platform, the normalized profile_url, and an email object {status, value}. A not_found status (with value null) is a normal result, not an error, and is still billed as one valid lookup. Handles one creator per call. To assemble a creator list first, use Similar Creators or AI Search — each match already includes an email for most creators; use this endpoint for the ones that come back null.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_url | Yes | Instagram, TikTok, or YouTube creator profile URL. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent safety profile, but the description adds genuinely non-structured behavior: not_found with null value is a normal result rather than an error, and it is still billed as one valid lookup. It also states the one-creator-per-call constraint.
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?
Four tight sentences, front-loaded with the core action, then parameter/response, then the billing caveat, then the sibling routing. No filler.
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 single-parameter lookup with an output schema and full annotation coverage, the description supplies everything an agent needs: input, normal-vs-error semantics, billing implication, cardinality, and sibling routing.
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 there is a single required parameter, so the schema already documents profile_url fully. The description only says 'Pass profile_url' and otherwise spends its words on output shape, adding little meaning beyond the schema. Baseline 3 applies.
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?
States a specific verb (looks up), resource (contact email), scope (one creator), and the supported platforms (Instagram, TikTok, YouTube). An agent can distinguish this from the batch/search siblings without opening schemas.
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?
Explicitly routes the agent: assemble a creator list with Similar Creators or AI Search first, then call this endpoint for the ones that return null emails. Names the alternatives and the condition that selects this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds creators similar to a seed account on Instagram, TikTok, or YouTube. platform and target_account are required; add limit (1–100, default 40) and optional filters (regions, languages, follower and play-count ranges, gender, ethnicity, creator type, face visibility, workspace dedup). Each match returns a rich profile: biography, email, followerCount, averagePlayCount / medianPlayCount, averageEngagementRate / medianEngagementRate, plus AI-inferred gender, ageRange, ethnicity, faceVisibility, accountPositioning tags, and an aiDescription, with a relevance score. Results are sorted by score descending. Billing is per delivered creator (data.count).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of creators to return. Default 40, range 1–100. Caps the billed count. | |
| filters | No | Optional filters applied before matching. All fields are optional. | |
| platform | Yes | Target platform. | |
| target_account | Yes | Seed account: a creator handle (with or without @) or profile URL to find similar creators for. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, open-world). The description adds genuinely non-obvious behavior: results are sorted by relevance score descending, and billing is per delivered creator tied to data.count, which is important cost context. It does not mention rate limits or error behavior, but the additions go meaningfully beyond the 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 the purpose, then parameters, then return shape in three dense sentences with no filler. The enumerated field list is somewhat long and partly duplicates the output schema, which costs a bit of efficiency.
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 purpose, required inputs, filter knobs, sorting, and billing, which is more than enough for a read-only search with a full output schema. The return-field enumeration is redundant given the output schema exists, but nothing an agent needs to call it correctly is missing.
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 baseline is 3. The description goes further by summarizing limit's default and range and by grouping the filter families (regions, languages, follower/play-count ranges, gender, ethnicity, creator type, face visibility, workspace dedup) into a scannable overview that helps the agent plan a call without reading the nested 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?
States a specific verb and resource (finds creators similar to a seed account) and names all three supported platforms, so the agent immediately knows the scope. It is clearly distinguishable from the Apollo/Similarweb siblings and from the other waveinflu tools (ai_search, email_lookup).
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?
Usage is implied by the purpose statement (find lookalike creators given a seed), and required vs optional inputs are spelled out. However, it never says when to prefer this over the sibling post_waveinflu_ai_search, nor any when-not conditions, so the routing guidance is left to inference.
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.
post_waveinflu_ai_searchpost_waveinflu_email_lookup3 fields changedInput schema / properties / profile_urlAdded value: +{
+ "description": "Instagram, TikTok, or YouTube creator profile URL.",
+ "example": "https://www.instagram.com/onkimia/",
+ "type": "string"
+}Input schema / properties / urlRemoved value: -{
- "description": "TikTok, Instagram, or YouTube creator profile URL.",
- "example": "https://www.instagram.com/onkimia/",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[
+ "profile_url"
+]post_waveinflu_similar_creators21 fields changedInput schema / properties / contentDirectionRemoved value: -{
- "description": "Natural-language description of the creator type you are looking for. Max 800 characters.",
- "example": "consumer tech creators covering AI apps, Android phones, productivity gadgets, and honest product reviews",
- "maxLength": 800,
- "type": "string"
-}Input schema / properties / filters / descriptionAdded value: +"Optional filters applied before matching. All fields are optional."Input schema / properties / filters / properties / creatorTypesAdded value: +{
+ "description": "Creator account types, e.g. [\"individual\", \"brand\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / filters / properties / ethnicitiesAdded value: +{
+ "description": "Inferred creator ethnicities.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / filters / properties / faceVisibilitiesAdded value: +{
+ "description": "Face-visibility classifications, e.g. [\"clear_face\", \"mixed\", \"no_face\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / filters / properties / gendersAdded value: +{
+ "description": "Inferred creator genders, e.g. [\"female\", \"male\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / filters / properties / maxPlayCountAdded value: +{
+ "description": "Maximum play / view count, measured by `playCountMetric`.",
+ "type": "number"
+}Input schema / properties / filters / properties / maxVideosAverageViewsRemoved value: -{
- "description": "Maximum average view / play count.",
- "type": "number"
-}Input schema / properties / filters / properties / minPlayCountAdded value: +{
+ "description": "Minimum play / view count, measured by `playCountMetric`.",
+ "type": "number"
+}Input schema / properties / filters / properties / minVideosAverageViewsRemoved value: -{
- "description": "Minimum average view / play count.",
- "type": "number"
-}Input schema / properties / filters / properties / playCountMetricAdded value: +{
+ "description": "Whether `minPlayCount` / `maxPlayCount` are compared against the median or the average play count.",
+ "enum": [
+ "median",
+ "average"
+ ],
+ "type": "string"
+}Input schema / properties / filters / properties / regions / descriptionPrevious value: -"Creator regions, e.g. [\"US\", \"GB\", \"JP\"]."New value: +"Creator regions (ISO country codes), e.g. [\"US\", \"GB\", \"JP\"]."Input schema / properties / filters / properties / workspaceDeduplicationEnabledAdded value: +{
+ "description": "When true, creators already saved in your workspace are excluded from the results.",
+ "type": "boolean"
+}Input schema / properties / limit / defaultPrevious value: -25New value: +40Input schema / properties / limit / descriptionPrevious value: -"Maximum number of creators to return. Default 25, range 1–100."New value: +"Maximum number of creators to return. Default 40, range 1–100. Caps the billed count."Input schema / properties / platform / descriptionPrevious value: -"Target platform. Currently supports youtube and tiktok."New value: +"Target platform."Input schema / properties / platform / enumPrevious value: -[
- "youtube",
- "tiktok"
-]New value: +[
+ "instagram",
+ "tiktok",
+ "youtube"
+]Input schema / properties / platform / examplePrevious value: -"youtube"New value: +"instagram"Input schema / properties / seedProfileUrlRemoved value: -{
- "description": "YouTube or TikTok creator profile URL as the seed for matching.",
- "example": "https://www.youtube.com/@mkbhd",
- "type": "string"
-}Input schema / properties / target_accountAdded value: +{
+ "description": "Seed account: a creator handle (with or without @) or profile URL to find similar creators for.",
+ "example": "@onkimia",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "platform"
-]New value: +[
+ "platform",
+ "target_account"
+]batch_useget_detailslist_categoriespost_waveinflu_email_lookuppost_waveinflu_similar_creatorssearchuseYour agent needs public Instagram data — a creator's posts and reels, what a hashtag is producing, what a video actually says. The official Graph API only sees accounts you already own, and needs app review to see those. **What you can ask for** • "Pull this creator's last 50 posts and reels with engagement counts." • "What is trending under #skincare this week, and which profiles keep appearing?" • "Transcribe this reel and tell me what the hook in the first three seconds is." • "Read the comments on this post and group the objections." • "Which reels use this song right now?" **How to use it** Point any MCP client at https://mcp.aisa.one/instagram/mcp and sign in with OAuth — there is no key to create or paste. 17 read tools: profiles (basic and full), a user's posts, reels and highlights, post and profile digests, post comments, reels search, trending reels, reels by song, hashtag and profile search, and media transcripts. **Why this rather than the source** Public profiles without owning the account, and no app review to sit through. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Size a creator's audience here, then ask the same agent what their brand's site traffic looks like or who to contact there — without adding a second server. **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** https://mcp.aisa.one/social/mcp for X plus Instagram, Reddit, Pinterest and YouTube; https://mcp.aisa.one/gtm/mcp for those plus Similarweb and Apollo.
Your agent needs X/Twitter data — who follows a competitor, what a community is posting, who quoted that tweet, what is trending in Japan. Normally that means applying for an X developer account, passing app review, and managing a quota per endpoint. **What you can ask for** • "Who follows @stripe, and which of them are verified?" • "Pull every reply and quote on this tweet and summarise what people object to." • "List this community's moderators and its posts this week." • "What is trending in Japan right now?" • "Give me the full thread context behind this link, including the long-form article." **How to use it** Point any MCP client at https://mcp.aisa.one/twitter-api/mcp and sign in with OAuth — there is no key to create or paste. 29 read tools: users (profile, about, batch lookup by id, search, followers, verified followers, followings, follow check), tweets (timeline, latest, mentions, advanced search, replies, quotes, retweeters, thread context, articles), communities, lists, Spaces and trends. **Why this rather than the source** No developer account to apply for, no app review, no per-endpoint quota to manage. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Ask for a handle's followers here, then ask the same agent for that brand's search traffic, its backlinks, or the people to contact — without adding a second server. **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** https://mcp.aisa.one/social/mcp for X plus Instagram, Reddit, Pinterest and YouTube; https://mcp.aisa.one/gtm/mcp for those plus Similarweb and Apollo.
Your agent needs to find video — which channels own a topic, which videos rank for a phrase, what exists in a given country and language. **What you can ask for** • "Which videos rank for 'rag pipeline tutorial' in the US this month?" • "Find channels publishing about MCP, sorted by relevance." • "What playlists cover this subject in Japanese?" • "Search videos uploaded this week only." **How to use it** Point any MCP client at https://mcp.aisa.one/youtube-search/mcp and sign in with OAuth — there is no key to create or paste. One search tool covering videos, channels and playlists, narrowed by country, language, upload date, duration and sort order. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the video here, then ask the same agent what the channel's site traffic is or what the same phrase does in Google — without adding a second server. **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** https://mcp.aisa.one/social/mcp for X plus Instagram, Reddit, Pinterest and YouTube; https://mcp.aisa.one/gtm/mcp for those plus Similarweb and Apollo.
Your agent needs what people are posting — across X, Instagram, Reddit, Pinterest and YouTube at once, not five accounts and five rate limits. **What you can ask for** • "What is being said about our brand this week on X and Reddit?" • "Find the creators posting about this category on Instagram and YouTube." • "Pull the replies and quotes on this tweet and the comments on that reel." • "What is trending in this country right now?" • "Which subreddits and hashtags keep coming up for this topic?" **How to use it** Point any MCP client at https://mcp.aisa.one/social/mcp and sign in with OAuth — there is no key to create or paste. 56 read tools across five platforms: X/Twitter (users, tweets, communities, lists, Spaces, trends), Instagram (profiles, posts, reels, highlights, transcripts), Reddit (search, subreddits, comment trees), Pinterest (pins, boards, search) and YouTube search. **Why this rather than the source** One login instead of five developer programmes, and no app review on any of them. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Measure the conversation here, then ask the same agent for the site traffic behind it or the people to contact — without adding a second server. **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** https://mcp.aisa.one/twitter-api/mcp · /instagram/mcp · /reddit/mcp · /pinterest/mcp · /youtube-search/mcp for one platform at a time; https://mcp.aisa.one/gtm/mcp adds Similarweb and Apollo.
Add one secure layer between your agents and this server.
