Your agent needs the two halves of a move at once — what people are posting about a ticker right now, and what the price and the news actually did.
What you can ask for • "What is X saying about $NVDA today, and what did the stock do?" • "Show the chatter and the price move for these five tickers side by side." • "Which tickers are being talked about most right now?" • "Pull the news and the snapshot behind this spike."
How to use it Point any MCP client at https://mcp.aisa.one/stock-pulse/mcp and sign in with OAuth — there is no key to create or paste. 4 tools: a combined stock-pulse call that joins X/Twitter chatter to the tickers mentioned, plus advanced tweet search, price snapshots and financial news.
Why this rather than the source One call instead of four, with the join already done.
It is also a door to the rest The same login reaches 26 sources and 580+ operations. Spot the move here, then ask the same agent for the filings or the fundamentals behind it — 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/finance/mcp for equities, crypto and prediction markets in one place.
Scored across 9 tools
Each tool has a clearly distinct role: price snapshot, news, Twitter search, combined pulse, execution, batch execution, schema details, catalogue listing, and search. Descriptions explicitly differentiate when to use each (e.g., twitter_stock_pulse vs get_twitter_tweet_advanced_search), so there is no ambiguity.
The naming is mixed: most data retrieval tools use get_ (e.g., get_financial_news), but there are bare verbs like 'use' and 'search', a compound noun 'twitter_stock_pulse', and 'batch_use'. While the get_ pattern dominates, the inconsistency reduces predictability.
Nine tools is well-scoped for a stock pulse server, covering core data retrieval (news, price, Twitter) plus meta tools for catalogue access (search, list_categories, use, batch_use, get_details). The count is neither too thin nor overwhelming.
The server covers news, price snapshot, Twitter search, and a combined pulse, but lacks historical price series, financial filings, and valuation metrics, which are mentioned as alternatives but not included. However, the search tool allows discovering and calling any other operation in the catalogue, mitigating these gaps.
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.
Recent news headlines for one stock: title, source, date, url and the echoed ticker, in a news array. ticker and limit are the only parameters — there is no full-text search and no date filter, so narrow by raising or lowering limit rather than by query. Use it for recent coverage of a company you have already identified. Headlines only: the article body is not returned, follow url for that. For the company's own filings rather than press coverage use get_financial_filings.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of news articles to return (default: 5, max: 10). | |
| ticker | No | The ticker symbol of the company. Omit for broad market news. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral constraints beyond that: headlines only (no body, follow url), no full-text search, no date filter, and the ability to omit ticker for broad market news (though schema mentions this, the description reinforces it). No contradiction with 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?
The description is dense but not excessively long. It front-loads the core purpose and output, then adds limitations and alternatives. Each sentence contributes value, though it could be tightened slightly by merging the ticker/limit clarification.
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 tool with two optional parameters, the description fully covers what an agent needs: output structure, limitations, and alternative tools. The output schema presence is acknowledged, but the description itself specifies the returned fields. No missing information for correct invocation.
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 both parameters are documented. The description adds value by explaining how to use limit as a narrowing mechanism given the lack of search/filter, and clarifies ticker's role. It doesn't introduce new semantics beyond the schema but provides usage context.
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 explicitly states the tool returns recent news headlines for a stock, listing the exact fields (title, source, date, url, ticker) in a news array. It clearly differentiates from siblings by noting the absence of full-text search and date filter, and contrasts with get_financial_filings.
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 provides explicit guidance: 'Use it for recent coverage of a company you have already identified,' and gives a specific alternative for filings ('use get_financial_filings'). It also explains how to narrow results via limit instead of query, covering when-not and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The current price of one stock in a single call: price, day_change, day_change_percent, and time (plus time_milliseconds). ticker is required. Use it whenever the question is "what is it trading at now" — this is the cheapest and fastest way to get one number. For a series of bars over a date range use get_financial_prices; for valuation multiples rather than the raw price use get_financial_financial_metrics_snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The stock ticker symbol (e.g. AAPL, MSFT). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds performance context ('cheapest and fastest way') and clarifies it returns real-time snapshot data. It does not mention pagination or limits, but for a simple single-stock snapshot this is acceptable. No contradiction with 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?
The description is efficiently structured: it front-loads the return fields, then states the required parameter, gives usage guidance, and names alternatives. No filler or redundant phrases. Every clause contributes to the agent's decision or call correctness.
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 an output schema present, the description doesn't need to explain return values, yet it still lists the fields. It covers the sole parameter, provides usage context, and differentiates from related tools. For a simple read-only snapshot tool, everything an agent needs to invoke it correctly is present.
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%: the only parameter `ticker` is fully documented in the schema ('The stock ticker symbol (e.g. AAPL, MSFT).'). The description repeats that `ticker` is required, which adds no new meaning beyond the schema. A baseline score of 3 is appropriate given exhaustive schema docs.
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 returns the current price of one stock with specific fields (`price`, `day_change`, `day_change_percent`, `time`). It explicitly distinguishes itself from sibling tools: `get_financial_prices` for historical series and `get_financial_financial_metrics_snapshot` for valuation multiples. The verb 'get' and resource 'financial prices snapshot' are specific, making the purpose unambiguous.
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 explicit when-to-use guidance: 'Use it whenever the question is "what is it trading at now"'. It also provides direct alternatives for different use cases, naming `get_financial_prices` for date range bars and `get_financial_financial_metrics_snapshot` for valuation multiples. This clearly tells the agent when to choose this tool and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search X posts by keyword or query with X's advanced search operators, sorted by Latest (default) or Top. This is the primary entry point for X content research when you do not yet have tweet IDs or handles. Supports operators in the query string such as from:, to:, since:, until:, min_faves:, and -filter:replies. Cursor-paginated; returns tweets with has_next_page and next_cursor. To search accounts rather than posts use get_twitter_user_search. To read one account's own posts use get_twitter_user_tweet_timeline.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The query to search for. | |
| cursor | No | The cursor to paginate through the results. First page is empty. | |
| queryType | Yes | The query type to search for. | Latest |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable functional behavior: cursor-paginated with has_next_page and next_cursor, and sorting by Latest or Top. It does not contradict annotations. It could have mentioned rate limits or error behavior, but those are not essential given 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?
The description is compact, front-loaded with the core purpose, then provides operator support, pagination behavior, and sibling routing. Every sentence earns its place, and the structure is logical and scannable.
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 the tool has an output schema and rich annotations, the description covers all necessary context: purpose, usage, operators, pagination, and alternatives. 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?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description enhances the query parameter by listing supported advanced operators (`from:`, `to:`, `since:`, `until:`, `min_faves:`, `-filter:replies`), and explains cursor pagination. This adds meaning beyond the generic schema description 'The query to search for.'
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's purpose: 'Search X posts by keyword or query with X's advanced search operators'. It explicitly identifies itself as the primary entry point for content research when no tweet IDs or handles exist, and differentiates from sibling tools like get_twitter_user_search and get_twitter_user_tweet_timeline by naming them directly.
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 explicit when-to-use guidance: 'This is the primary entry point for X content research when you do not yet have tweet IDs or handles.' It also gives clear alternatives: 'To search accounts rather than posts use get_twitter_user_search. To read one account's own posts use get_twitter_user_tweet_timeline.' No ambiguity remains.
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.
Assemble everything behind "what is X saying about stocks right now" in one call.
Searches X/Twitter for a topic, extracts every $TICKER cashtag mentioned in the results, then fetches a price snapshot for the most-mentioned symbols — optionally recent company news too.
Use this when you need the posts AND the market data behind them together. Doing it yourself means one search call, parsing cashtags, then one price call per symbol, then joining the results; this returns the joined bundle.
Returns the raw tweets, per-symbol mention counts, price snapshots, a coverage
block saying which upstream sources succeeded or failed, and a billing block with
the calls made.
It does NOT rank, score, or interpret. mentions is a raw count, not a heat ranking —
you decide what "hot" means and what the numbers imply. If you only need the posts,
use get_twitter_tweet_advanced_search. If you already know the symbols, use
get_financial_prices_snapshot directly.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | 7d | |
| topic | Yes | ||
| max_tickers | No | ||
| include_news | No |
| 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, so the safety profile is covered. The description adds valuable behavioral context: it returns raw tweets, mention counts, price snapshots, a coverage block for upstream failures, and a billing block. It also explicitly states the tool does NOT rank or interpret, which prevents misuse. Minor gap: no mention of rate limits or pagination, but the coverage/billing disclosure is strong.
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 well-structured and front-loaded with the core value proposition. It uses short paragraphs and bullet-like lists to convey the workflow, return contents, and exclusions. Every sentence earns its place, and the explicit 'does NOT' clarification prevents misinterpretation.
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 are documented elsewhere. The description covers the workflow, the joined data, the coverage/billing blocks, and the non-interpretation caveat. It lacks explicit mention of pagination or rate limits, but for a read-only aggregation tool with an output schema, this is nearly complete.
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 0%, so the description must compensate. It explains the overall flow (topic → cashtags → prices) and mentions 'most-mentioned symbols' which maps to max_tickers, and 'optionally recent company news' which maps to include_news. However, it does not explain the format of `since` (e.g., '7d' default) or the exact semantics of max_tickers beyond 'most-mentioned'. The description adds meaning but leaves some parameter details to the 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?
The description clearly states the tool's function: it searches X/Twitter for a topic, extracts $TICKER cashtags, fetches price snapshots, and optionally news, then returns a joined bundle. It distinguishes itself from siblings by explicitly naming alternatives like get_twitter_tweet_advanced_search and get_financial_prices_snapshot.
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 explicitly states when to use this tool ('when you need the posts AND the market data behind them together') and when not to use it, naming the alternatives for posts-only or known-symbols cases. It also explains the manual multi-step alternative, making the tradeoff clear.
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.
batch_useget_detailsget_financial_newsget_financial_prices_snapshotget_twitter_tweet_advanced_searchlist_categoriessearchtwitter_stock_pulseuseYour agent needs markets — prices and fundamentals for listed companies, the filings behind them, crypto, and what the prediction markets put the odds at. **What you can ask for** • "Pull this company's income statement, cash flow and balance sheet for the last 8 quarters." • "What did insiders buy or sell, and when?" • "Snapshot prices for these 50 tickers, then the OHLC history for the three that moved." • "What are the current odds on this event across Kalshi and Polymarket?" • "Screen for companies matching these financial criteria." **How to use it** Point any MCP client at https://mcp.aisa.one/finance/mcp and sign in with OAuth — there is no key to create or paste. 49 tools: prices and snapshots, income statements, balance sheets and cash flows, metrics and ratios, earnings and analyst estimates, filings and line-item search, insider trades, macro interest rates, news, a screener; CoinGecko spot prices, market tables, OHLC, per-venue tickers and trending; Kalshi and Polymarket markets and trades; plus EDINET filings for Japan. **Why this rather than the source** Equities, crypto and event markets behind one account, so a cross-asset question is one conversation. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the number here, then ask the same agent what X is saying about the ticker today — 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/marketpulse/mcp · /crypto-market-data/mcp · /prediction-market-data/mcp · /stock-pulse/mcp for one slice each.
Your agent needs company financials it can compute on — statements, ratios, earnings, estimates, filings and insider activity as structured data, not a PDF. **What you can ask for** • "Give me 8 quarters of income statement, balance sheet and cash flow for this ticker." • "What do analysts estimate for next quarter, and how did the last four surprise?" • "Find this exact line item across every filing." • "Who bought or sold as an insider in the last 90 days?" • "Screen for profitable companies under this valuation with growing revenue." **How to use it** Point any MCP client at https://mcp.aisa.one/marketpulse/mcp and sign in with OAuth — there is no key to create or paste. 21 tools: prices and snapshots, income statements, balance sheets, cash-flow statements, financial metrics and snapshots, earnings, analyst estimates, company facts, filings and filing items, line-item search, a screener, insider trades, macro interest rates, news, plus EDINET documents and filing digests for Japanese issuers. **Why this rather than the source** Statements as fields you can compute on, and a screener in the same place. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the fundamentals here, then ask the same agent what social is saying about the ticker — 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/finance/mcp for equities, crypto and prediction markets in one place.
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 crypto prices it can rely on — spot, ranked market tables, history, OHLC, per-venue tickers, and what is trending right now. **What you can ask for** • "What is the price of these 20 tokens in USD and EUR right now?" • "Give me the top 100 by market cap with 24h and 7d change." • "Chart this coin's price over the last year, hourly." • "Where does this token trade, and at what spread per venue?" • "What is trending on CoinGecko today?" **How to use it** Point any MCP client at https://mcp.aisa.one/crypto-market-data/mcp and sign in with OAuth — there is no key to create or paste. 21 CoinGecko tools: simple price and token price by contract, supported currencies, coin list and detail, ranked markets, history, market charts and ranges, OHLC, per-coin tickers, categories, exchanges and their tickers, token data and charts, and trending. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Price the token here, then ask the same agent what X is posting about it — 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/finance/mcp for equities, crypto and prediction markets in one place.
Add one secure layer between your agents and this server.
