Data API or tool router? How EveryInfra and Monid split an agent's calls

On November 3, 2026, from 16:33 to 16:45 Singapore time (SGT), we sent one request six times. It went to the EveryInfra xiaohongshu/search capability: the Chinese keyword for "matcha latte", sort "most liked" (most_liked), page one. Every call returned 20 notes and cost $0.005556, and every field name was on the catalog list. Two of the calls had their own timer: they took 3.9 and 4.3 seconds. But across the six runs, the 18 top-three slots held 16 different notes.

That result shows what a daily agent job can hold constant. The request shape, the field names, the price and the error format can stay fixed. The result set cannot, so each stored row must keep its sort order and timestamp. Because those four things stay fixed, a daily job fits a dedicated data API.

The calls that an agent makes once, and did not know it would make, belong on a tool router such as Monid. On November 3, 2026 its home page showed 2,800+ tools. Monid sent us material on October 29. According to it, discover and inspect are free. run is billed per call from one balance, at the price on the tool card.

This article started as a draft from the Monid team. We kept its argument. An agent's tool calls come in two kinds: repeated calls and discovered calls. The two kinds should not be wired the same way. We changed one thing and added our own test runs.

The change is in the routing rule. The draft's example named only three platforms for the daily list: Xiaohongshu, Douyin and TikTok. We replaced that with the full EveryInfra catalog for the day: 106 platforms, grouped by category. Now only the real long tail goes to the router. The added runs are the matcha latte searches above, a note detail call, a comments call and a Douyin search. We also sent two requests that were wrong on purpose.

For numbers about Monid, we quote two kinds of facts only. The first kind is the runs that Monid made on its side on October 29, 2026. The second kind is dated facts from its own site. We did not repeat its billed calls.

A quick note on the platform, for readers outside China. Xiaohongshu, also known abroad as RedNote, is a Chinese social app. People post notes there: short posts with photos or video, a title and tags. Each note has counts for likes, saves (collects), comments and shares.

Brands and analysts watch it the way they watch Instagram or TikTok, but in Chinese. It is a good test case here. Many teams track it every day, and a general-purpose router lists several competing endpoints for it.

Two kinds of tool calls: the repeated ones and the discovered ones

Monid's draft opens with one exercise. Pull last week's tool calls out of your agent and sort them by how often the same call repeats. In Monid's words, the repeated calls are a short list: the platforms you track, the fields you keep, the schedule you run. The same request runs several times a day.

The rest is a long tail. For example, a user asks for the weather at a venue on the day of an event. Someone wants a creator's follower count on a platform you do not track. Someone else wants a company's latest funding round, or a page that a plain HTTP fetch cannot open. Each item in that tail can come from a different company, with its own key, schema and signup. Most of them get called a few times a year.

The two parts want opposite things. For the repeated calls, the most valuable property is that nothing changes. Stable field names keep the agent's code and the downstream tables aligned. A stable price lets finance budget ahead. A stable error format means you write the retry logic once.

Anthropic's guide Writing effective tools for agents treats a tool as an agreement between a deterministic system and a non-deterministic agent. It asks for clear names, clean boundaries between tools, and responses with useful context. For the long tail, the most valuable property is reach. The agent does not know in advance which tool it will need. So it should not be configured for each one. It should find the tool when it needs it, see the price, call it once and move on.

The mistake is to serve both parts the same way. Integrate the long tail one vendor at a time, and the agent spends its first week collecting API keys. Push the daily job through a general router, and you lose the fixed schema that kept it cheap to maintain.

There is also a cost on the model side: the more tools an agent sees, the more often it picks the wrong one. The RAG-MCP paper ran an MCP stress test. Retrieving the relevant tools before showing them to the model raised selection accuracy from 13.62% to 43.13%. It also cut prompt tokens by more than half.

Earlier work such as ToolLLM and Gorilla found the same: more APIs make both choice and arguments harder. One developer runs 58 MCP servers and more than 680 tools. On Reddit's r/mcp, he wrote that tool choice gets clearly worse past 30 to 60 tools. His fix was to load tool descriptions lazily and to give each specialized agent only 10 to 20 tools.

So the sensible shape is one direct line for the repeated calls and one router for everything else. This is not a choice between two products. Both services speak MCP, and both can sit in the same agent client at once. A short rule tells the agent which one to use for each call. The next sections explain what Monid is, how long the EveryInfra daily list really is, and then go through the test runs.

What Monid is: three verbs and one balance

Monid describes itself as the OpenRouter for agent tools. The phrase describes a product shape, not a business tie. OpenRouter puts many models behind one key and one balance. Its quickstart says it serves hundreds of models through a single endpoint and handles fallbacks automatically. According to Monid's October 29 material, Monid does the same thing one layer up. It covers the tools an agent calls after it picks a model.

Monid's positioning page, read on November 3, 2026, sums it up in one line. OpenRouter is one key, every model, pay per token. Monid is one skill, every tool, pay per call. We use the comparison only to describe the shape of the product. It says nothing about any relationship between the two companies.

We read the Monid home page on November 3, 2026. It showed 2,800+ tools and $1 in free credit for a new account. The material Monid sent us on October 29 gave the same two figures.

According to that October 29 material, the catalog covers web search, scraping, and people and company enrichment. It also covers social platform data (Chinese platforms included), maps and reviews, e-commerce, finance and generative media. Billing, in Monid's own words: pay per call from one balance, with no subscription. Discovering and inspecting a tool are free; only the run is billed, at the price shown on the tool card.

In the same material, the workflow is three verbs. discover is a free semantic search over the catalog. The agent describes the job in plain words and gets a ranked list of endpoints, each with a price and a health status. inspect is also free and returns the input schema, the price and the docs for one endpoint. run is the only billed step, charged from the prepaid balance at the price inspect showed.

An agent can reach Monid through MCP, a skill file, a command-line tool, or a REST API. The Monid MCP quickstart (Monid MCP setup guide, read on November 3, 2026) gives the server address https://mcp.monid.ai/v1 and OAuth sign-in. It has separate steps for Claude Code, Codex and other clients. The skill file is at monid.ai/SKILL.md. According to Monid's material, an agent that you tell to "set up" that address learns the three verbs by itself. A machine-readable overview is at monid.ai/llms.txt.

The EveryInfra daily list: 106 platforms, 569 capabilities

The first line of the routing rule is "platforms on the list go to EveryInfra", so the length of the list decides how useful the rule is. The example rule in Monid's draft named three platforms: xiaohongshu, douyin, tiktok. With that rule, Amazon reviews, Google Maps reviews, LinkedIn jobs and Reddit posts also leave the list. Yet the EveryInfra catalog has fixed fields and a fixed price for all of them. So this section lists the whole catalog.

The data comes from the free EveryInfra catalog, GET /api/v1/social/catalog, read on November 3, 2026 at 16:32 SGT. It lists 106 platforms and 573 capabilities, of which 569 were available that day. The other four carried available=false (g2/compare, jd/reviews, temu/search and wechat_oa/wechat_index), so leave those out of the daily list for now. The categories follow the same rules as our /market page: content and social, reviews, e-commerce, jobs and business, and search, web and markets. The table below names all 106 platforms, sorted within each category by how many capabilities each one has.

Two notes on using this list. First, the list moves. The catalog can add platforms or capabilities on any day, and it can mark one as unavailable for a while. So do not hard-code the list in the rule. At the start of a session, have the agent call the free everyinfra_list_capabilities tool or the catalog endpoint. Then fill the list from what comes back.

Second, a list of platforms is still coarse. On one platform, some capabilities run every day and some return data only with certain arguments. Xiaohongshu alone has 17 available capabilities. They are search, note detail, comments, comment replies, user profile, user notes and user search. They also include topics, trending, product search, product detail, product reviews, followers and note location. The last three are batch comments for many links, video detail and a creator content ranking.

All of them cost $0.005556 per call, except the creator content ranking at $0.016. If you write the list by capability, the agent can see each call's price and arguments in the rule. The details are on the Xiaohongshu data API page and the Xiaohongshu search capability page.

One change to the routing rule: list it all, send only the rest to Monid

With the list in hand, the rule can stay short. We rewrote Monid's draft rule with the same structure. We changed only the platform line, and we added one fallback: when in doubt, ask EveryInfra first, and move to Monid only on unknown_capability. The rule is plain text for the agent to read, so it can live in a system prompt or in a project instructions file.

For a daily job on a platform in the list below, call everyinfra_call_api.
Use the platform's own language for keywords. If the task says "this week"
or "today", sort by time. Record platform, action, params, the call time and
charged_usd for every call.
For a platform outside the list, a one-off lookup, or a tool that is not data,
use Monid: discover first, then inspect (both free); run only when the price
fits the budget. Run is billed at the price inspect showed. Record each price
and run id.
If you are not sure a platform is on the list, call EveryInfra first.
If it returns HTTP 400 with error.code unknown_capability (nothing charged),
then use Monid.
List (EveryInfra catalog, read 2026-11-03; refresh at the start of each
session with everyinfra_list_capabilities):
airbnb, alibaba1688, aliexpress, amazon, app_store, apple_maps, behance,
bilibili, bing, bing_maps, bluesky, booking, capterra, clutch, company_data,
craigslist, crexi, crypto_market, crypto_news, dailymotion, deviantart,
dewu, dice, discord, douban, douyin, dribbble, duckduckgo, duckduckgo_maps,
ebay, etsy, eventbrite, expedia, facebook, flickr, g2, gab, github,
glassdoor, google_ads_transparency, google_maps_reviews, google_news,
google_play, google_shopping, google_trends, indeed, instagram, iqiyi, jd,
kalshi, kuaishou, lemmy, linkedin, mastodon, medium, naukri, naver,
netease_music, nextdoor, odysee, patreon, pinterest, polymarket,
producthunt, quora, realtor, reddit, rumble, seek, shopee, similarweb,
snapchat, soundcloud, spotify, stepstone, substack, taobao, telegram, temu,
thomasnet, threads, tiktok, toutiao, tripadvisor, trustpilot, truth_social,
tumblr, twitch, twitter, upwork, vk, walmart, web, wechat_channels,
wechat_oa, weibo, xianyu, xiaohongshu, xing, yahoo_finance, yandex, yelp,
youku, youtube, zhihu, zillow

We tested that fallback. At 16:41:00 SGT we asked for a platform that is not on the list, lemon8. EveryInfra answered in 0.24 seconds with HTTP 400. The error.code was unknown_capability, and the allowed field listed all 106 platform names. The first line of next_steps said that nothing was charged.

At 16:40:52 SGT we sent the Xiaohongshu search a sort value that does not exist: hot. That is the sort name of the second endpoint in Monid's draft. The API answered in 0.11 seconds with HTTP 422 and a did_you_mean of most_liked. Its allowed list gave the five valid values, and again nothing was charged.

The difference between the two errors matters for routing. HTTP 400 unknown_capability means "this job is not mine", so the agent should move to Monid. HTTP 422 invalid_value means "this job is mine, but an argument is wrong", so the agent should fix the argument from allowed and try again, not move away.

The fallback lets the rule lean toward asking first. Say the list is a day out of date. Calling EveryInfra first then costs one uncharged round trip of a fraction of a second, and then the rule sends the job on.

Daily platforms should not take the other branch first. Monid's own October 29 material says that two endpoints for the same platform name their sorts differently and return different field names. So once a job repeats every day, the agent needs one endpoint, one sort and one schema (the quote is at the end of "Test one" below). The same advice is in the section of our docs on using EveryInfra with Monid and in the Monid entry on our partners page.

Both MCP servers in one client

The two services can run side by side because of how MCP itself is built. The MCP architecture overview explains it. A host program creates one MCP client for each MCP server, and each client keeps its own connection. The host can be Claude Code, Claude Desktop, Cursor, VS Code, or a program you write. Once connected, the host merges the tool lists from all servers and gives them to the model. The model picks a tool on each call.

So EveryInfra and Monid can live in the same host without knowing about each other. The split depends only on the tool descriptions the model reads and on the rule you write. On the wire, messages use JSON-RPC 2.0. Remote servers use the Streamable HTTP transport. Listing and calling tools follow the tools section of the specification.

In Claude Code, two commands are enough. EveryInfra uses an API key, which you keep in an environment variable and pass with --header. Monid's remote server uses OAuth, according to the Monid MCP setup guide (read on November 3, 2026). After you add it, type /mcp in Claude Code, select monid, and complete the sign-in. The flag --scope user makes both servers available in all of your projects.

The Claude Code MCP documentation also describes local and project scopes. The project scope writes to .mcp.json in the project root, which suits a team that shares one setup. New to MCP? Start with the Claude Code MCP quickstart and our MCP server page.

# EveryInfra: API key auth; keep the key in an environment variable only
claude mcp add --transport http everyinfra https://api.everyinfra.com/mcp \
  --scope user --header "Authorization: Bearer ${EVERYINFRA_API_KEY}"

# Monid: remote MCP with OAuth (then type /mcp in Claude Code, pick monid, sign in)
claude mcp add --transport http monid https://mcp.monid.ai/v1 --scope user

If your client reads an mcpServers file, the setup looks like the block below. One detail trips people up. In a Claude Code .mcp.json file, a remote server needs "type": "http". An entry with only url fails with a configuration error when the file loads.

Cursor reads almost the same format. VS Code uses the top-level key servers instead of mcpServers. Gemini CLI uses httpUrl for a Streamable HTTP address, and Codex uses TOML. The table after the block lists the differences across five common clients. Each row comes from that client's official documentation, read on November 3, 2026.

{
  "mcpServers": {
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    },
    "monid": { "type": "http", "url": "https://mcp.monid.ai/v1" }
  }
}

With both servers connected, the model sees both sets of tool descriptions on every turn, and that has a cost. At 16:42:41 SGT we sent one tools/list request to the EveryInfra MCP server. It returned 12 tools. everyinfra_list_capabilities reads the catalog, everyinfra_call_api calls any data capability, and everyinfra_get_job fetches async results. The rest cover search, captcha solving, AI chat, the account and support tickets.

The whole response body was 16,247 bytes. At a rough four bytes per token, that is about 4,060 tokens. The number is small because we did not turn each of the 569 capabilities into its own tool. One general everyinfra_call_api tool plus a free catalog tool lets the model look up what it needs first.

Anthropic gives a useful comparison in Introducing advanced tool use. Loading the descriptions of 50+ MCP tools up front took about 72K tokens. Loading them on demand through tool search kept only a small part of that.

The host helps here too. The Claude Code environment variable reference says tool search is on by default (ENABLE_TOOL_SEARCH). So MCP tool descriptions do not all go into the context at once. A tool output above 10,000 tokens triggers a warning, and the default limit is 25,000 tokens (MAX_MCP_OUTPUT_TOKENS).

In our runs, the five search pages of 20 Xiaohongshu notes each were 35,538 to 51,999 bytes of raw JSON. Much of it was long strings that an analysis does not need, such as image URLs, avatar URLs and page tokens. So for daily jobs, have the agent keep only the columns it stores. Or run the HTTP API from a script and write the result to a file, so the rows never pass through the model's context.

Anthropic's Code execution with MCP describes this pattern. The model writes code that calls the tools, and the intermediate data stays in the execution environment. Only the conclusion comes back to the conversation.

Test one: matcha latte with three sorts and two languages

These are the main test runs for this article. Every request went from Singapore to the EveryInfra HTTP API at POST /api/v1/social. The platform was xiaohongshu, the capability search, and the keyword the Chinese for matcha latte. We changed only the sort, the page, the date range, and in one case the keyword language.

The time is the total client time, network round trip included. The price is the value of billing.charged_usd in each response. Our editor ran the first three rows at 16:33 SGT, and we ran the rest while writing, with the same test key.

The request is short. Here is the 16:40:40 call, with the response cut down to the first note and the billing field. The full field list is on the Xiaohongshu search capability page. New readers can get a key from the quickstart in our docs.

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"xiaohongshu","action":"search",
       "params":{"keyword":"抹茶拿铁","sort":"most_liked"}}'

{
  "platform": "xiaohongshu", "action": "search", "count": 20,
  "pagination": { "page": 1, "has_more": true },
  "next_page_token": "pt1.…",
  "results": [
    { "id": "69a509f400000000220335a9",
      "like_count": 16056, "collect_count": 2657, "comment_count": 6223,
      "share_count": 3261, "posted_at": "2026-03-02T04:15:14+00:00",
      "is_video": false, "is_cooperation_note": true }
  ],
  "billing": { "charged": true, "charged_usd": 0.005556 }
}

Start with the sort. "Most liked" and "newest" answer two different questions. The 16:33 most-liked page had a median of 1,427.5 likes and 747.5 saves. None of its 20 notes was under 30 days old, and the oldest was posted on May 28, 2025. By age: 0 notes under 30 days, 12 at 30 to 179 days, 5 at 180 to 364 days, 3 over a year.

The newest page had 20 notes posted on November 2 and 3, with a median of 0 likes. The two pages shared no notes at all. If an agent saves both as "matcha latte top 20", nobody downstream can tell which page answers "what is most popular" and which answers "what are people saying today".

Next, the keyword language. The English keyword "matcha latte", sorted by most likes, had a median of 1,011 likes. Eleven of its 20 notes were videos, against 9 on the Chinese keyword's page. The oldest was posted on March 18, 2023, and five were more than a year old. It shared 4 notes with the 16:33 Chinese page.

So one topic returns two overlapping but different sets in Chinese and in English. The English page had five notes more than a year old; the Chinese page had three. That is why the routing rule says "use the platform's own language for keywords": it stops the agent from searching a Chinese platform in English by default.

Page two and the date filter are worth a look too. With the next_page_token from page one, page two returned 20 new notes, with no overlap. The median dropped to 194.5 likes. At 2.34 seconds it was the fastest call of the session. Each page counts as one call at the same price.

With date_range=last_30_days added, the page came back with one note. It was posted on October 9 and had 1,857 likes. The call took 9.45 seconds, the slowest of the session. The catalog is direct about this argument. A narrow range such as the last 30 days may return fewer than 20 notes per page. For full pages, pair it with sort=newest, and a page with no notes is not charged.

This page had one note, so it was charged $0.005556 as usual. Say your daily job is "the most liked matcha latte notes from the last 30 days". A steadier approach is to page through the newest notes each day, store them, and sort by likes yourself. That works better than one "last 30 days + most liked" request a day.

The median across nine synchronous calls was 3.6 seconds, with a range from 2.34 to 9.45 seconds. For a job that runs once a day, that is fast enough. An agent that makes a dozen calls in one conversation turn can add "mode": "async" to the request. The API then returns a job id at once. The agent fetches the result with everyinfra_get_job or GET /api/v1/jobs/{job_id}. The async_hint field in every synchronous response says the same.

Now the numbers from Monid's side, from October 29, 2026. Monid used Monid's Xiaohongshu tool page for this test. It picked two Xiaohongshu note search endpoints from two different companies in its catalog. It ran each once with the same Chinese keyword, and ran the first one again with the English keyword. According to Monid's material, that tool page listed 49 endpoints on the day.

The row counts, times and results in the table below come from the material Monid sent us, and the times are US Pacific time. We did not repeat these runs, and we do not rank them against ours. The dates differ, the sort arguments differ, and the two sides answered different questions.

Monid drew the same conclusion from its runs that we drew from ours: the sort order has to travel with the data.

Here is the passage from Monid's October 29 material, lightly edited: "Same keyword, same day, two endpoints, two different questions answered. An agent that files both as 'top 20' has lost the only thing that made them comparable."

The same material says that the two endpoints use different sort names and different field names. So once a query becomes a daily series, the agent needs one endpoint, one sort and one schema. That is the point at which the call moves from the router to the direct line. Monid describes its own method in its guide on how to get Xiaohongshu data through an API.

Test two: the same request six times, 16 different notes in the top three

From 16:33 to 16:45 SGT, the exact same request ran six times: {"keyword": <the Chinese keyword>, "sort": "most_liked"} on page one. It ran once at 16:33:22. At 16:36 our editor made a first test run of the example script below. It ran again at 16:40:40. At 16:45 our editor ran the script three more times, once for each language version of this article. The script prints only the top three, so the top three is what we can compare across all six runs.

Across six runs, the 18 top-three slots held 16 different notes. The note with 16,056 likes came first at 16:33 and at 16:40. The note with 20,972 likes came third at 16:36 and first in the first 16:45 run. Each of the other 14 notes appeared once. We compared the top three of every pair of runs: 13 of the 15 pairs shared no note, and 2 pairs shared one. The full 20-note pages from 16:33 and 16:40 shared only 7 notes.

First, be clear about what the request asks for. The catalog names this sort value "most liked" (most_liked).

EveryInfra returns page one of Xiaohongshu search, sorted that way, at that moment. It is not a full sort of every matcha latte note by like count. So page one does not promise to hold the most liked notes on the whole platform.

The raw responses show this. The top note at 16:33 and at 16:40 had 16,056 likes. But the top note at 16:36 had 53,316 likes, and the three 16:45 runs had 20,972, 22,440 and 21,468 likes at the top. None of these notes was in the full 20-note pages from 16:33 and 16:40.

The three 16:45 runs happened within one minute, and their top threes shared no note. So the platform's page one can change within minutes, even within one minute. The API side stayed the same every time. Every call returned HTTP 200 with 20 notes, and every call cost the same $0.005556. Every field name in the 16:33 and 16:40 responses was on the catalog's response_fields list. A field or two appears only when it has a value, such as poi_id when a note carries a place.

This has three direct consequences for a daily job. First, be clear about what can be fixed. The request shape, the field names, the price and the error format can and should stay fixed. The result set cannot. Do not trust any setup that promises "the same top 20 every day" from one request.

Second, store the request conditions and the time with the data: the sort, the page, the keyword and the call time. Leave one out, and a week later you cannot say which question that batch of rows answers.

Third, if you want a stable ranking, do not rely on the top few results of a single request. Page a little deeper each day and merge the pages into your own table by note id. Then sort by a rule you define, such as like count. That ranking is one you can reproduce.

Here is the third point with this session's data. The 16:33 and 16:40 page ones held 20 notes each. Merged and deduplicated by note id, they gave 33 different notes, 13 more than either page alone. Sorted by likes, the 16,056-like note comes first, and the next merge can compute the same result. It does not depend on which page the platform serves the next minute.

For each stored row, keep at least the columns below. The sample values come from the first note of the 16:40:40 response.

The cost of merging is easy to work out too. Page two at 16:41 shared no note with page one. So pages one and two give 40 different notes per keyword per day. Run both pages in the morning and again in the afternoon, and one keyword takes 4 calls a day. At $0.005556 per call, that is about $0.022 a day and $0.67 for 30 days. The extra money buys a table you can reproduce and compare. Next week you can still see which note entered the top 40 on which day, and how its likes grew.

Test three: note detail, comments and Douyin

Daily jobs rarely stop at search. With a batch of notes in hand, you usually want details and comments for the top few. Sometimes you also want the same keyword on a second platform. The three calls below all ran between 16:41 and 16:42 SGT, through the same API and the same request shape; only platform and action changed.

The note detail adds fields that search does not return. These are the poster's ip_location, the full tags and topics lists, and has_goods, which says whether a product is attached.

The top note in this session is a sponsored note: its is_cooperation_note was true. It promotes a rose-flavored coffee series and describes three drinks. One of them is the rose matcha latte, and the note says that matcha fans will love it. But the title does not say "matcha", and none of its nine tags do. The matcha latte is one drink in a series.

That tells anyone running a daily monitor two things. To decide if a note is about the keyword, read the body text, not only the title and tags. And count sponsored notes on their own, with relevance judged from the body. Otherwise one or two paid posts can lift a whole week's average likes. The full field list is on the note detail capability page.

The comments call returned 15 top-level comments, from 1,213 likes down to 3. Each carries a sub_comment_count, and the 15 together had 650 replies under them. The response had has_more set to true, so next_page_token gets the next page. On this page every ip_location was empty, which shows that a commenter's region is not always present; downstream statistics should not assume it is.

The comment fields also include author_is_ai_agent, which was false for all 15. To analyze sentiment or selling points in comments, see the comments capability page. Our earlier article on reading Xiaohongshu comments with Claude Code dynamic workflows goes further.

A Douyin search page holds 10 videos and costs $0.008333 per call, or $8.33 per 1,000 calls. The Xiaohongshu search costs $5.56 per 1,000. Both are the listed catalog prices. The 10 videos had a median of 6,179.5 likes, and the top one had more than 1.17 million. They were posted between February 2025 and September 2026.

The field names are not identical across the two platforms. Douyin adds author_follower_count, music, hashtags and is_pinned. But shared fields such as like_count, comment_count, share_count and posted_at use the same names. So a cross-platform table only has to handle the extra columns on each side. The Douyin data API page and the Douyin search capability page list every field. The matching TikTok capabilities are on the TikTok data API page.

Example script: the daily job and the one-off job together

The Python below is the smallest working example of the two services together, written with Requests. The first half is the daily job: the EveryInfra xiaohongshu/search call with one fixed request shape, printing the top three notes and the charge. The second half is a one-off job: find a company's logo from its domain. That is not daily platform data, so it goes to Monid: discover, then inspect, and run only if the price fits the budget. Both keys come from environment variables, and the script contains no key values.

import os

import requests

EVERYINFRA_API_KEY = os.environ["EVERYINFRA_API_KEY"]
MONID_API_KEY = os.environ["MONID_API_KEY"]
MONID = "https://api.monid.ai/v1"
MONID_HEADERS = {"Authorization": f"Bearer {MONID_API_KEY}"}
MAX_PRICE_USD = 0.01  # do not run a Monid tool that costs more than this per call

# 1. The daily job: EveryInfra xiaohongshu/search, one fixed request shape
resp = requests.post(
    "https://api.everyinfra.com/api/v1/social",
    headers={"Authorization": f"Bearer {EVERYINFRA_API_KEY}"},
    json={"platform": "xiaohongshu", "action": "search",
          "params": {"keyword": "抹茶拿铁", "sort": "most_liked"}},
    timeout=120,
)
resp.raise_for_status()
body = resp.json()
for note in body["results"][:3]:
    print(note["like_count"], note["collect_count"], note["posted_at"][:10], note["url"])
print("EveryInfra:", len(body["results"]), "notes, charged (USD):", body["billing"]["charged_usd"])

# 2. A one-off lookup that is not a daily platform: discover, inspect, run on Monid
found = requests.post(f"{MONID}/discover", headers=MONID_HEADERS, timeout=60,
                      json={"query": "company logo image URL from a domain", "limit": 3}).json()["results"]
# discover adds ranking and price fields to each result; inspect and run take only the fields that name the tool
SHOWN_ONLY = ("providerName", "description", "price", "score", "scoreBreakdown", "tags", "metrics", "hints")
tool = {key: value for key, value in found[0].items() if key not in SHOWN_ONLY}
detail = requests.post(f"{MONID}/inspect", headers=MONID_HEADERS, timeout=60, json=tool).json()
price = detail["price"]["amount"]["value"]
print("Monid tool:", detail["endpoint"], "price (USD):", price)
if price <= MAX_PRICE_USD:
    run = requests.post(f"{MONID}/run", headers=MONID_HEADERS, timeout=120,
                        json={**tool, "input": {"pathParams": {"company": "starbucks.com"}}}).json()
    print("Monid run:", run.get("runId"), run.get("status"), run.get("output"))

Our editor first ran this script on November 3, 2026 at 16:36 SGT, then three more times at 16:45, once for each language version. Each full run took 6.4 to 7.7 seconds. The EveryInfra half returned 20 notes each time and was charged $0.005556. Its top three are the 16:36 and 16:45 rows in the dot grid above.

On the Monid half, the first discover result in all four runs was an endpoint that returns a company logo from a domain. inspect showed its price at that moment as $0, so the script went on to run. The run came back with status COMPLETED and a logo image URL. The MAX_PRICE_USD line is a plain but useful guard. discover and inspect are free, so an agent can always read the price first. It can skip any tool above the budget and hand that decision back to a person.

Monid's own October 29 material gives a warning that fits here: discovery is a ranking, not a guarantee. A capability phrase such as "Xiaohongshu note search" ranks well. A long, casual sentence with proper nouns in it can rank endpoints that have nothing to do with the task. So read the top results before you run one, which is free. The "discover, then inspect, then run only within budget" steps in our rule follow that advice.

The bill: what a daily job costs per month

The most direct payoff of fixed fields and a fixed price is that you can work out the bill in advance. Below is the monthly cost of a Xiaohongshu matcha latte monitor at the catalog prices of November 3, 2026. A month has 30 days here, and every call is charged. In practice failed calls and empty pages are not charged, so these numbers are a ceiling. The 16 Xiaohongshu capabilities other than the creator content ranking cost $0.005556 per call, and Douyin search costs $0.008333 per call. The full price list is on the pricing page.

The numbers are small, but what matters is that they can go into a budget ahead of time. The request and the price do not change. So the month-end bill does not move because the model picked a different endpoint.

The long tail is billed another way: inspect the price before each run, record each call, and add up what actually happened at month end. The charged calls listed in this article add up to 13 calls and $0.075005. Our own 6 calls while writing cost $0.036113. Our editor's 7 calls (three at 16:33, one at 16:36 and three at 16:45) cost $0.038892.

Limits: what this split covers and what it does not

The routing rule decides where a call goes. It does not decide whether you should collect the data.

Xiaohongshu's user service agreement and privacy policy set terms for using platform content and user information. Processing personal information in mainland China also falls under the Personal Information Protection Law. The Network Data Security Management Regulations also apply, in force since January 1, 2025. For a daily job, the most practical step is to store only the columns your analysis uses. A note id, the title, the engagement counts, the post time, the sort and the call time are usually enough. Leave out author nicknames, avatars and commenter profiles unless you need them, and when you do, have a clear purpose and a retention period.

The rule has limits of its own, and each one has a simple answer.

For remote MCP servers, OAuth sign-in is defined in the authorization section of the MCP specification.

The last limit is the model. However well the tools are wired, a model can still pick the wrong one or fill an argument wrong. MCP-Universe tested models against real MCP servers. The best result, from GPT-5, was a 43.72% success rate. MCP-Bench built tasks on 28 servers and 250 tools that look more like real work. It scores calls that span several tools and steps on their own.

So the rule in this article is written to be plain. The list is explicit, the error codes are told apart, and the agent reads the price before it spends money. Each of those removes a guess from the model's job. In Claude strict tool use with a data API we describe another approach. Strict argument schemas stop the model from building an invalid request at all.

What changed recently

Tool calling has moved fast in the last few months. Each row below is from July 2026 or later. The last column says what the change means for the "daily jobs on a data API, long tail on a router" split.

FAQ

Does Xiaohongshu have an official note search API?

As of November 3, 2026, the Xiaohongshu open platform mainly serves shop and e-commerce ERP apps, with APIs for orders, products and after-sales. On October 19, 2026 it retired a category prediction API. Search, detail and comments for public notes are not part of it. The EveryInfra xiaohongshu/search capability costs $0.005556 per call; see the Xiaohongshu data API page.

Am I charged if the platform is not on the EveryInfra list?

No. A platform outside the list returns HTTP 400 unknown_capability, and a wrong argument returns HTTP 422 with did_you_mean. Neither is charged; the test runs (November 3, 2026, 16:40 to 16:41 SGT) are in the routing rule section above.

How many tools should one agent load?

There is no hard number. RAG-MCP found that with many tools, retrieving first and then choosing raised accuracy from 13.62% to 43.13%. The r/mcp developer with more than 680 tools saw choices get clearly worse past 30 to 60. For how to split work between subagents and the main loop, see Claude Code subagents for TikTok accounts.

References

1. EveryInfra data capability catalog, GET /api/v1/social/catalog, EveryInfra, read 2026-11-03 at 16:32 SGT.
2. Architecture overview, Model Context Protocol documentation, read 2026-11-03.
3. Release notes for the 2026-07-28 MCP specification, MCP blog, 2026-07-28.
4. Specification: Tools, MCP specification, 2026-07-28 version.
5. Specification: Authorization, MCP specification, 2026-07-28 version.
6. Specification: Transports, MCP specification, 2026-07-28 version.
7. The MCP Ruby SDK reaches Tier 1, MCP blog, 2026-10-30.
8. MCP Registry, official MCP registry, read 2026-11-03.
9. JSON-RPC 2.0 Specification, JSON-RPC Working Group.
10. Connect Claude Code to tools via MCP, Claude Code documentation, read 2026-11-03.
11. MCP quickstart, Claude Code documentation, read 2026-11-03.
12. Environment variables, Claude Code documentation, read 2026-11-03.
13. Model Context Protocol, Cursor documentation, read 2026-11-03.
14. Model Context Protocol, OpenAI Codex documentation, read 2026-11-03.
15. Use MCP servers in VS Code, VS Code documentation, read 2026-11-03.
16. MCP servers with Gemini CLI, Gemini CLI documentation, read 2026-11-03.
17. Connectors and MCP servers, OpenAI platform documentation, read 2026-11-03.
18. Quickstart, OpenRouter documentation, read 2026-11-03.
19. FAQ, OpenRouter documentation, read 2026-11-03.
20. Writing effective tools for agents, Anthropic Engineering.
21. Introducing advanced tool use, Anthropic Engineering.
22. Code execution with MCP, Anthropic Engineering.
23. Building agents: When to fold subagents into your main agent loop, Anthropic, 2026-10-22.
24. RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation, arXiv:2505.03275.
25. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs, arXiv:2307.16789.
26. Gorilla: Large Language Model Connected with Massive APIs, arXiv:2305.15334.
27. MCP-Universe: Benchmarking Large Language Models with Real-World Model Context Protocol Servers, arXiv:2508.14704.
28. MCP-Bench: Benchmarking Tool-Using LLM Agents with Complex Real-World Tasks via MCP Servers, arXiv:2508.20453.
29. RFC 9110: HTTP Semantics, IETF.
30. RFC 6585: Additional HTTP Status Codes, IETF.
31. RFC 9457: Problem Details for HTTP APIs, IETF.
32. RFC 9728: OAuth 2.0 Protected Resource Metadata, IETF.
33. RFC 8707: Resource Indicators for OAuth 2.0, IETF.
34. RFC 9207: OAuth 2.0 Authorization Server Issuer Identification, IETF.
35. The OAuth 2.1 Authorization Framework, draft 13, IETF.
36. Skills over MCP: How Bloomberg helped standardize agent skills at scale, Bloomberg, 2026-10-21.
37. Treasury for agents, Stripe Newsroom, 2026-10-21.
38. An analysis of 15,465 public MCP servers, The Hacker News, 2026-10-06.
39. A report on the Pi agent, MCP and code mode, The New Stack.
40. MCP Server and SI Agent Government Hackathon, US General Services Administration, September to November 2026.
41. A report on an OpenRouter competitor's seed round, Semafor, 2026-10-16.
42. A post on running 58 MCP servers and 680+ tools, Reddit r/mcp.
43. Requests: Quickstart, Requests documentation.
44. Xiaohongshu user service agreement (in Chinese), Xiaohongshu, read 2026-11-03.
45. Xiaohongshu privacy policy (in Chinese), Xiaohongshu, read 2026-11-03.
46. Xiaohongshu open platform (in Chinese), Xiaohongshu, read 2026-11-03, including the 2026-10-19 notice.
47. Personal Information Protection Law of the People's Republic of China (in Chinese), Cyberspace Administration of China.
48. Network Data Security Management Regulations (in Chinese), State Council, published September 2024, in force from 2025-01-01.
49. A Huxiu report on Xiaohongshu and AI (in Chinese), Huxiu, 2026-10-16.
50. Monid home page, read 2026-11-03 ("Live · 2800+ tools", "Start with $1 in free credit"); see the link in the article.
51. Monid, "The OpenRouter for agent tools", positioning page, read 2026-11-03; see the link in the article.
52. Monid, MCP quickstart, setup documentation, read 2026-11-03; see the link in the article.
53. Monid, Xiaohongshu tool page, 49 endpoints listed on 2026-10-29; see the link in the article.
54. Monid, "How to get Xiaohongshu (RedNote) data through an API", guide, read 2026-11-03; see the link in the article.