superagnt

Name: superagnt
Author: superagnt

Live data for AI agents over one MCP connection: social media data from LinkedIn, X, Reddit, YouTube, TikTok, Instagram, and Facebook, plus lead enrichment, work email finding and verification, company data, and SEO research. Also gives agents a workspace Postgres database, schedules, webhooks, and shareable dashboards, so they can store what they fetch and act on it. OAuth sign-in, first calls free, no card required.

该来源不提供完整文件导出（国内平台多为平台内托管），仅存元数据与原链

接入信息

传输形态: http
鉴权方式: 鉴权未知
端点: https://superagnt--superagnt.run.tools

鉴权方式未标注，请核对官方文档后再接入——不要直接使用以下片段

{
  "mcpServers": {
    "superagnt": {
      "url": "https://superagnt--superagnt.run.tools"
    }
  }
}

能力清单

工具	说明
data_youtube_video_screenshot	Endpoint returns a screenshot given timestamp in seconds
data_youtube_channel_search_continuation	This endpoint gets search the next list of search results in a given Youtube channel using the channel ID
data_youtube_channel_search	This endpoint gets search results in a given Youtube channel using the channel ID
data_youtube_channel_shorts	Get the latest shorts published by a Youtube channel
data_youtube_channel_videos_continuation	Get the next list of videos published by a Youtube channel
data_youtube_channel_details	This endpoint get all available details about a given channel ID
data_youtube_youtube_channel_id	This endpoint get the channel ID of a Youtube Channel given the channel name
data_youtube_channel_videos	Get the latest videos published by a Youtube channel
data_youtube_post_channel_videos	Get channel videos
data_youtube_audio_videos_continuation	Get the next list of videos published under an audio
data_youtube_audio_videos	Get the latest video published under an audio
data_youtube_audio_details	This endpoint get available details about a given audio
data_youtube_video_recommendation_continuation	This endpoint will return the continuation list of recommended videos based on a former call to /video/recommendation/ endpoint.
data_youtube_video_recommendation	This endpoint returns a list of recommended videos based on a given a video ID
data_youtube_video_comments	This endpoint returns a list comments under a given Youtube video
data_youtube_video_subtitles	Get the available subtitles of a Youtube Video
data_youtube_video_details	Get all publicly available details about a Youtube Video
data_youtube_video_data	Get downloadable links of the Video
data_youtube_youtube_search_continuation	This endpoint gets the next search result using the token from the former search result
data_youtube_youtube_search	This endpoint will a specific number of videos for a specific keyword, note that the maximum is 40 videos per request
data_youtube_trending_videos	This endpoint returns the list of trending videos given a country
data_youtube_video_comments_continuation	This endpoint return the next page of Youtube video comments, you will need to use the continuation token from previous API call
data_youtube_get_channel_email_by_url	Returns the public contact email(s) for a YouTube channel, given its channel URL (e.g. https://www.youtube.com/@handle).
data_youtube_get_channel_email_by_id	Returns the public contact email(s) for a YouTube channel given its channel ID (e.g. UCdcUmdOxMrhRjKMw-BX19AA).
data_tiktok_video_details	Return Video Details
data_tiktok_user_s_videos	Return User Videos
data_tiktok_collection_videos_details	Return a collection details and videos
data_tiktok_user_s_videos_continuation	Return the next list of User Videos
data_tiktok_user_s_details	Return User Details
data_tiktok_search_accounts	Return Search Result
data_tiktok_search_videos	Return Search Result
data_x_continuation_user_s_media_get_user_medias_continuation	This endpoint returns the list of a user's medias
data_x_continuation_user_s_media_post_user_medias_continuation	This endpoint returns the list of a user's medias
data_x_user_s_media_get_user_medias	This endpoint return a list of user's media given a user ID
data_x_user_s_media_post_user_medias	This endpoint return a list of user's medias given a user ID
data_x_continuation_user_s_likes_get_user_likes_continuation	This endpoint returns the list of a user's Likes
data_x_continuation_user_s_likes_post_user_likes_continuation	This endpoint returns the list of a user's likes
data_x_user_s_likes_get_user_likes	This endpoint return a list of user's likes given a user ID
data_x_user_s_likes_post_user_likes	This endpoint return a list of user's likes given a user ID
data_x_continuation_user_s_followers_get_user_followers_39ed2926	This endpoint returns the list of a user's followers
data_x_continuation_user_s_followers_post_user_follower_9aa97da1	This endpoint returns the list of a user's followers
data_x_user_s_followers_get_user_followers	This endpoint return a list of user's followers given a user ID
data_x_user_s_followers_post_user_followers	This endpoint return a list of user's followers given a user ID
data_x_user_s_following_continuation_get_user_following_657efcd9	This endpoint gets the next list of following using the token from the former call
data_x_user_s_following_continuation_post_user_followin_13bcf780	This endpoint gets the next list of following using the token from the former call
data_x_user_s_tweets_get_user_tweets	This endpoint return a list of user's tweets given a username
data_x_user_s_tweets_post_user_tweets	This endpoint return a list of user's tweets given a username
data_x_user_s_tweets_continuation_get_user_tweets_continuation	This endpoint return the next list of user's tweets given a username
data_x_user_s_tweets_continuation_post_user_tweets_continuation	This endpoint return the next list of user's tweets given a username
data_x_user_details_get_user_details	This endpoint returns the public information about a Twitter profile
data_x_user_details_post_user_details	This endpoint returns the public information about a Twitter profile
data_x_user_about_get_user_about	Twitter/X Transparency
data_x_tweet_replies_continuation_get_tweet_replies_continuation	This endpoint returns the next list of reply tweets
data_x_tweet_replies_continuation_post_tweet_replies_co_01fc069d	This endpoint returns the next list of reply tweets
data_x_tweet_user_favoriters_continuation_get_tweet_fav_38b0802a	This endpoint returns the next list of user who favorited the tweet
data_x_tweet_user_retweets_continuation_get_tweet_retwe_f7cafbf1	This endpoint returns the next list of user who retweeted the tweet
data_x_tweet_details_get_tweet_details	This endpoint return general information about a tweet
data_x_tweet_details_post_tweet_details	This endpoint return general information about a tweet
data_x_tweet_user_favoriters_get_tweet_favoriters	This endpoint returns a list of user who favorited the tweet
data_x_tweet_user_retweets_get_tweet_retweets	This endpoint returns a list of user who retweeted the tweet
data_x_tweet_replies_get_tweet_replies	This endpoint returns a list of reply tweets
data_x_tweet_replies_post_tweet_replies	This endpoint returns a list of reply tweets
data_x_user_s_following_get_user_following	This endpoint returns the list of following
data_x_user_s_following_post_user_following	This endpoint returns the list of following
data_x_lists_tweets_continuation_get_lists_tweets_continuation	This endpoint returns the next list of tweets in a given Twitter list
data_x_search_continuation_get_search_search_continuation	This endpoint return search continuation results
data_x_search_continuation_post_search_search_continuation	This endpoint return search continuation results
data_x_topic_classification_get_ai_topic_classification	Allows you to automatically extract meaning from text by identifying recurrent themes or topics
data_x_detect_post_translate_detect	This endpoint will return the Language of the Text
data_x_named_entity_recognition_get_ai_named_entity_recognition	Locate and classify named entities mentioned in text into pre-defined categories such as person names, organizations, locations
data_x_sentiment_analysis_get_ai_sentiment_analysis	Analyze text to determine if the emotional tone of the message is positive, negative, or neutral.
data_x_translate_post_translate	Return Translated Text and the source language if it wasn't specified
data_x_available_locations_beta_get_trends_available	Get the list of available locations
data_x_get_trends_near_a_location_beta_get_trends	Returns the top 50 trending topics for a specific id (woeid), if trending information is available for it.
data_x_geo_search_beta_get_search_geo	Perform Geo search
data_x_lists_tweets_get_lists_tweets	This endpoint return a list of tweets in a given Twitter list
data_x_lists_details_get_lists_details	This endpoint returns the public information a Twitter Lists
data_x_search_get_search_search	This endpoint return search results
data_x_search_post_search_search	This endpoint return search results
data_x_hashtag_get_hashtag_hashtag	This endpoint return hashtag results
data_x_hashtag_post_hashtag_hashtag	This endpoint return hashtag results
data_x_hashtag_continuation_get_hashtag_hashtag_continuation	This endpoint return the next hashtag results
data_x_hashtag_continuation_post_hashtag_hashtag_continuation	This endpoint return the next hashtag results
data_instagram_search_users_by_keyword	Search for users using a text query.
data_instagram_media_by_explore_section_id	Retrieve media content from a specific explore section.
data_instagram_explore_sections_list	Get the available explore content sections (e.g. art, sports).
data_instagram_cities_by_country_code	Get a list of cities based on a country code.
data_instagram_media_by_location_id	Get posts shared from a particular location.
data_instagram_download_link_by_media_id_or_url	Get a direct download link for media (image/video).
data_instagram_media_info_by_url	Get media details using the media link.
data_instagram_related_profiles_by_user_id	Suggest similar profiles based on a user ID.
data_instagram_reels_by_user_id	Get reels posted by the user.
data_instagram_media_list_v2_by_user_id	Improved version for fetching user media.
data_instagram_media_list_by_user_id	Fetch a list of media posts for the given user ID.
data_instagram_user_info_v2_by_username	Enhanced version of user info by username.
data_instagram_user_info_by_user_id	Fetch user information using the user ID.
data_instagram_media_shortcode_from_media_id	Get the media shortcode from a media ID.
data_instagram_username_from_user_id	Retrieve the username using the user ID.
data_instagram_tagged_media_by_user_id	Fetch media in which the user was tagged.
data_instagram_reposts_by_user_id	Get reposts posted by the user.
data_instagram_locations_by_city_id	List locations available in a specific city.
data_instagram_location_info_by_location_id	Retrieve information about a specific location.
data_instagram_web_profile_info_by_username	Get public web profile data for a username.
data_instagram_music_info_by_music_id	Retrieve information about a music track used in posts or reels.
data_instagram_media_by_hashtag	Get posts tagged with a specific hashtag.
data_reddit_similar_subreddits	Similar Subreddits
data_reddit_post_duplicates	Post Duplicates
data_reddit_subreddit_moderators	Subreddit Moderators
data_reddit_subreddit_rules	Subreddit Rules
data_reddit_user_overview	User Overview
data_reddit_search_users	Search Users
data_reddit_best_popular_posts	Best Popular Posts
data_reddit_controversial_posts_by_subreddit	Controversial Posts By Subreddit
data_reddit_user_post_rank_in_subreddit	User Post Rank In Subreddit
data_reddit_subreddit_info	Subreddit Info
data_reddit_comments_by_subreddit	Comments By Subreddit
data_reddit_post_comments_with_sort	Post Comments With Sort
data_reddit_profile	Profile
data_reddit_post_comments	Post Comments
data_reddit_user_stats	User Stats
data_reddit_search_posts	getSearchPosts
data_reddit_search_subreddits	getSearchSubreddits
data_reddit_new_subreddits	getNewSubreddits
data_reddit_popular_subreddits	getPopularSubreddits
data_reddit_post_details	Post Details
data_reddit_posts_by_subreddit	Posts By Subreddit
data_reddit_top_comments_by_username	Top Comments By Username
data_reddit_popular_posts	Popular Posts
data_reddit_top_posts_by_subreddit	Top Posts By Subreddit
data_reddit_comments_by_username	Comments By Username
data_reddit_top_posts_by_username	Top Posts By Username
data_reddit_posts_by_username	Posts By Username
data_reddit_rising_popular_posts	Rising Popular Posts
data_reddit_top_popular_posts	Top Popular Posts
data_facebook_get_facebook_video_post_details	This endpoint retrieves details of a Facebook video post. It accepts a video_id as a parameter and returns information such as the video title, description, duration, view count, and more.
data_facebook_get_facebook_posts_comments	Get the details of comments on the latest Facebook Page posts (up to 10 comments per post). Use end_cursor to retrieve additional comments beyond the first 10.
data_facebook_get_facebook_post_details	Retrieves details of a Facebook post based on the provided link.
data_facebook_get_facebook_post_attachement_details	Retrieves details about the attachments (e.g., images, videos, links) and all reactions (likes, loves, comments, shares, etc.) associated with a Facebook post.
data_facebook_get_facebook_posts_comment_replies	Fetches replies to a specific comment on a Facebook post. Requires `comment_feedback_id` and `expansion_token`, which are returned by the `get_facebook_post_comments_details` endpoint when `include_reply_info` is set to `true`.
data_facebook_fetch_archive_ad_details	This endpoint allows you to retrieve detailed information about a specific ad in the archive based on its archive ID. You can filter the results by page ID, country, and flags indicating whether the ad is non-political or AAA-eligible.
data_facebook_fetch_page_ad_details	This endpoint retrieves detailed information about a specific Facebook page based on the provided page ID. This includes key page details such as name, profile URL, verification status, and more, but does not return ad data directly.
data_facebook_fetch_search_ads_pages_get	This endpoint retrieves detailed information about ad pages based on a search query, returning up to 26 ads per request. Use the end_cursor parameter to retrieve additional ads if needed.
data_facebook_fetch_search_ads_pages_post	This endpoint retrieves detailed information about ad pages based on a search query, returning up to 26 ads per request. Use the end_cursor parameter to retrieve additional ads if needed.
data_facebook_download_media	Download media (images, videos, audio) from Facebook URLs.
data_facebook_fetch_search_videos	This endpoint retrieves information about Facebook Videos based on a specified search query. Use the end_cursor parameter to paginate through additional video results if more data is available.
data_facebook_get_group_videos	Get the Facebook Group Videos (up to 6 videos per request). Use end_cursor to retrieve more videos.
data_facebook_get_marketplace_listing_item_details	This endpoint fetches detailed information for a specific Marketplace listing, including fields like listing URL 🔗, primary photo 📸, price 💰, location 📍, status 📊, seller details 👤, delivery options 🚚, title 🏷️, and comparable pricing 🛒.
data_facebook_get_facebook_groups_posts	Get the latest Facebook Groups posts (up to 3 posts per request). Use end_cursor to retrieve more posts.
data_facebook_get_facebook_group_details	This endpoint extracts key data from Facebook groups, enabling quick access to information by entering the group URL and clicking "Test Endpoint"—gather details such as 👥 Total Members, 🆕 New Members, 📅 Creation Date, 📝 Group Description, 🆔 Group ID, 📜 Group Rules, 📊 Member Activity, and more.
data_facebook_get_page_reels	Get the latest Facebook Page Reels (up to 10 reels per request). Use end_cursor to retrieve more posts.
data_facebook_get_page_videos	Get the Facebook Page Videos (up to 6 videos per request). Use end_cursor to retrieve more videos.
data_facebook_get_facebook_pages_posts	Get the latest Facebook Page posts (up to 3 posts per request). Use end_cursor to retrieve more posts.
data_facebook_get_facebook_page_details	This endpoint is designed to extract essential data from Facebook pages. By simply entering the page URL and clicking the "Test Endpoint" button, users can quickly gather the desired information. 📰 Ad Page ID, 🔍 Ad Status, 🏠 Address, 👤 Bio, ⏰ Business Hours, 💰 Business Price, 🛋️ Business Services, 📂 Category, 👥 Confirmed Owner Label, 📅 Creation Date, ✉️ Email, 👥 Followers Display, 📸 Image, 🔗 Image Alt, 👍 Likes Count, 🗺️ Maps Address, 📞 Phone, ⭐ Rating, 📊 Rating Count, 🏷️ Title, 🌐 URL, 🌐 Website
data_facebook_get_marketplace_rental_property_search_results	Fetch rental property listings from the marketplace.
data_facebook_get_marketplace_city_coordinates	Retrieve precise geographical data for a given city with the get_city_coordinates endpoint, returning the city's full name, latitude, and longitude coordinates; these coordinates can then be used as location filters in the search results endpoint.
data_facebook_get_marketplace_vehicles_search_results	Fetch Vehicles listings from the marketplace.
data_facebook_get_marketplace_categories	This endpoint retrieves marketplace category details, providing the seo_url and category id values, which can be used as parameters for other endpoints to refine marketplace searches.
data_facebook_fetch_search_posts	This endpoint retrieves information about Facebook Posts based on a specified search query and a location_uid. Use the end_cursor parameter to retrieve additional posts data if needed.
data_facebook_get_marketplace_search_results	This endpoint retrieves Facebook Marketplace items by entering a search term and configuring filters like 🌍 Location, 💲 Price Range, 📅 Date Range, 📏 Radius, 🗂️ Category, and 🔄 Sort Order—enabling fast, customized searches for marketplace listings.
data_facebook_get_facebook_group_id	Get the unique ID of any Facebook Group
data_facebook_get_facebook_group_metadata_details	Get group metadata details (name, id, url, image). Use group_id to retrieve specific group information.
data_facebook_get_seller_details	Retrieve seller details given the seller id
data_facebook_get_supported_countries	The get_supported_countries endpoint retrieves a list of all available country codes that can be used in other endpoints, such as filtering ads by country. This ensures that you are using valid country codes when making requests.
data_facebook_fech_search_ads_keywords	The Fetch Search Ads Keywords endpoint allows you to search for ads based on a specified query. You can filter ads by country, status (Active or Inactive), and ad type.
data_facebook_fetch_search_locations	This endpoint retrieves information about Facebook locations based on a specified search query.
data_facebook_fetch_search_people	This endpoint retrieves information about Facebook People based on a specified search query and a location_uid. Use the end_cursor parameter to retrieve additional people data if needed.
data_facebook_fetch_search_pages	This endpoint retrieves information about Facebook pages based on a specified search query and a location_uid. Use the end_cursor parameter to retrieve additional pages if needed.
data_facebook_get_facebook_post_id	Extract the post ID from the Facebook URL
data_facebook_get_facebook_page_id	Get the unique ID of any Facebook Page
data_agnt_people_email_finder	Find a verified professional email for a person at a company. Identifier fields are at the TOP LEVEL of the body (NOT inside an `identifiers` object): `first_name` + `last_name` (or `full_name`) plus `domain` (or `company` / `company_name`). LinkedIn URL/handle is not currently supported here — if that is all you have, call `/people/enrich` first with `identifiers.linkedin_url` to resolve name + domain, then call this endpoint. agntdata waterfalls cheapest-first across providers until an email is returned (or your `max_cost_cents` budget is exhausted). If you already know the email and want to look up other fields, use `/people/enrich` instead with `identifiers.email`.
data_agnt_people_email_verifier	Verify the deliverability and reputation of an email address. Returns a normalized status (valid, accept_all, unknown, invalid) and provider-agnostic signals (smtp, mx, disposable, webmail, gibberish).
data_agnt_people_enrich	Enrich a person with normalized fields (email, mobile, job title, company, LinkedIn URL, location, …). REQUIRES a `identifiers` object containing ONLY `email` and/or `linkedin_url` — these are the unique handles we use to resolve the person upstream. `first_name`, `last_name`, `domain`, `company`, etc. are NOT accepted here and will return a VALIDATION_ERROR. If you only have a name + company, call `/people/email-finder` first to obtain an email, then pass that email here. Optional `fields[]` narrows the waterfall to only fetch the fields you care about. agntdata runs a field-aware waterfall: it stops once all requested fields are filled or your `max_cost_cents` budget is exhausted.
data_agnt_people_find_mobile	Find a mobile phone number for a person. REQUIRES a `identifiers` object containing ONLY `email` and/or `linkedin_url`. `first_name`/`last_name`/`domain` are NOT accepted — if you only have a name + company, call `/people/email-finder` first. `linkedin_url` is the strongest signal. agntdata waterfalls across providers that expose mobile data, cheapest-first, until a number is found or your budget is exhausted.
data_agnt_people_search	Search the people graph using structured filters (job title, company, location, seniority, department, …). Returns paginated profile summaries.
data_agnt_people_bulk_enrich	Enrich up to 100 people in one call. Each input record requires `email` and/or `linkedin_url` (either at the top level of the input object or nested under `identifiers`). `first_name`/`last_name`/`domain` are NOT accepted — if you only have name+company, call `/people/email-finder` per record first. Each input runs the same field-aware waterfall as `/people/enrich`. Use `max_cost_cents_per_record` to cap per-record spend.
data_agnt_companies_discover	Find companies matching a set of criteria. Pass either a natural-language `query` or structured `filters` (industry, headcount, location, technology, funding, keywords, …). Returns paginated company summaries.
data_agnt_companies_domain_emails	Return the email addresses found for a domain (or company name) along with first/last name, position, type (personal/generic), and verification metadata when available.
data_agnt_companies_enrich	Enrich a company with normalized firmographic fields (industry, headcount, HQ, founded year, technologies, funding, …). REQUIRES a `identifiers` object containing one or more of: `domain`, `name` (or `company_name`), `linkedin_url` (or `company_linkedin_url`). `domain` is the strongest signal — prefer it when available. Optional `fields[]` narrows the waterfall. Field-aware waterfall same as `/people/enrich`.
data_agnt_companies_search	Search the company graph using structured filters (industry, headcount, location, technology, …). Returns paginated company summaries.
data_agnt_companies_bulk_enrich	Enrich up to 100 companies in one call. Each input must include at least one of: `domain`, `name` (or `company_name`), `linkedin_url` (top-level on the input object — NOT nested under `identifiers` like the single-record endpoint). `domain` is the strongest signal. Each input runs the same field-aware waterfall as `/companies/enrich`. Use `max_cost_cents_per_record` to cap per-record spend.
data_agnt_companies_intelligence	Fetch a single intelligence signal for a company by domain. Choose `funding`, `competitors`, or `technographics`. Each signal is flat-priced.
data_web_scrape	Fetches a single URL and returns its content. Default is clean main-content `markdown` — cheapest and right for almost everything; just read the markdown. Reach for the pricier options only when the task truly needs them: the `json` format with a `schema` runs an LLM to extract structured fields (costs several credits per page — prefer scraping markdown and parsing it in code), and `proxy: enhanced` forces heavy anti-bot handling. Scrape only the specific pages you will actually use. Handles JavaScript-rendered pages.
data_web_search	Runs a web search and returns result URLs + snippets — cheap; use this first and read the snippets. Add `scrapeOptions` ONLY when you actually need the full text of the pages, because it then downloads and bills EVERY result — keep `limit` small when you do (a few results, not dozens). To read specific pages, prefer searching first and then scraping just the one or two URLs you chose. Supports web, news, and image sources.
data_web_map	Returns a list of URLs found on a website, quickly. Useful for discovering the structure of a site before scraping specific pages. Optionally order results by relevance to a `search` term.
data_seo_google_search	Runs a live Google search and returns the ranked results: organic listings with position, title, URL and snippet, plus SERP features (featured snippets, people-also-ask, local pack). Use it to check what ranks for a keyword, verify a page's position, or find competitor pages. Default depth is 10 results, which is the cheapest shape and right for most checks; raise `depth` only when you truly need deeper pages, since cost scales per 10 results. Search operators (site:, inurl:, filetype:) work but multiply the upstream cost roughly 5x, so use them deliberately. At default depth this is one of the cheapest calls in the source — well under half a cent — so prefer it for quick spot checks.
data_seo_google_ai_mode_search	Runs the query through Google's AI Mode and returns the AI-generated answer with its cited sources and references. Use it to see how Google's AI answers a question and which pages it cites, which is the core check for answer-engine optimization: is your (or a competitor's) content being used as a source? Costs about 2x a classic search.
data_seo_keyword_ideas	Expands up to 200 seed keywords into related keyword ideas, each with search volume, CPC, competition and keyword difficulty (difficulty is at keyword_properties.keyword_difficulty in each row; volume and CPC at keyword_info). Ideas come from category-level expansion, so sorting by search volume surfaces unrelated head terms; the default order is relevance, keep it for topical work and filter instead. Cost scales with rows returned, so keep `limit` at the default 100 unless the task genuinely needs more (hard cap 1000).
data_seo_keyword_overview	Returns full metrics for the exact keywords you pass: search volume, CPC and competition (keyword_info), keyword difficulty (keyword_properties.keyword_difficulty), trend history and SERP characteristics. Use this when you already know the keywords and need their numbers; use keyword_ideas when you need to discover keywords.
data_seo_search_intent	Classifies each keyword's search intent (informational, navigational, commercial, transactional) with a probability score. Use it to split a keyword list into content types: informational keywords get articles, transactional ones get landing pages.
data_seo_ranked_keywords	Returns the keywords a domain (or a specific page) currently ranks for in Google, with position, search volume, and the ranked URL. The core competitor research call: point it at any domain to see its organic footprint. Cost scales with rows, so keep `limit` at the default 100 and use `filters` (e.g. position <= 20) instead of pulling thousands of rows. Row shape: items[].keyword_data.keyword_info.search_volume, items[].keyword_data.keyword_properties.keyword_difficulty, items[].ranked_serp_element.serp_item.rank_absolute.
data_seo_keyword_gap	Compares two domains' organic rankings keyword by keyword. Each row carries keyword_data plus first_domain_serp_element (target1's ranking) and second_domain_serp_element (target2's) with rank_absolute, rank_group and the ranked URL. The classic gap query is: competitor ranks well, you don't — filters: [["first_domain_serp_element.rank_absolute",">",20],"and",["second_domain_serp_element.rank_absolute","<=",10]] with target1 = you, target2 = the competitor (a missing element means that domain does not rank at all). Cost scales with rows; the default 100 is enough for most gap analyses.
data_seo_competitors	Returns the domains that compete with the target in organic search, ranked by keyword overlap (the `intersections` field), with visibility and traffic estimates for each. Note: the first row is the target itself, and generic high-overlap mega-domains (youtube.com, linkedin.com) dominate the default output — skip the self row and filter, e.g. filters: [["intersections",">",50]], or sort with order_by: ["metrics.organic.count,desc"] and judge overlap yourself. Feed the survivors into keyword_gap or backlink_gap.
data_seo_domain_overview	One-call summary of a domain's organic footprint: domain rank, number of ranking keywords, estimated organic traffic and its value, split by position buckets. The cheap first call when qualifying a domain: run this before deciding whether a deeper ranked_keywords or backlinks pull is worth it.
data_seo_backlinks_summary	Returns a domain or page's backlink profile at a glance: total backlinks, referring domains, domain rank, spam score, broken links, and anchor/TLD distributions (flat object at result[0], no items array). The `rank` here is the target domain's own backlink-authority rank — a different metric from the per-referring-domain `rank` in backlink_gap/referring_domains rows, so the same domain can carry different numbers in each. Use it to qualify a site's authority in one cheap call before deeper link analysis.
data_seo_referring_domains	Lists the domains linking to a target, each with rank, backlink count, first/last seen dates and spam score. This is the outreach-prospecting call: the sites already linking to a competitor are the sites most likely to link to you. Cost scales with rows; default 100 is right for most pulls.
data_seo_backlink_gap	Finds domains that link to one or more competitor targets but NOT to the excluded target (you). The output is a ready-made link-building prospect list; chain it with an email-finder tool to turn rows into outreach. Response shape: each row's referring domain lives at items[].domain_intersection["1"], ["2"], ... keyed by the 1-based index of your `targets` array, with that referring domain's own authority score in `rank` (0-1000ish, higher is stronger; this is the referring domain's rank, a different metric from the target-domain rank in backlinks_summary). Default sort is rank descending. When ranking prospects, check referring_domains and backlinks together — a huge backlink count with few referring domains usually means sitewide boilerplate links, not authority.
data_seo_page_audit	Fetches a single URL and returns its full on-page SEO signals instantly: title/meta/heading structure, content stats, internal and external link counts, load timings, and every detected on-page issue (missing tags, thin content, broken elements). The cheapest call in this source. Use it per-page; for whole-site crawls a page-by-page loop over the site's key URLs works well.
data_seo_ai_visibility	Returns aggregated metrics on how often large language models mention or cite the target domains or keywords in their answers. Navigation: the data lives at result[0].aggregated_metrics (by platform/location/language) — the items array is often legitimately EMPTY, so do not treat items_count 0 as no data. Priced per request (roughly 40x a search, ~18 cents) regardless of returned rows, so run it for periodic brand tracking, not in loops.
data_seo_tech_stack	Returns the technologies detected on a domain: CMS, analytics, marketing tools, payment providers, frameworks, hosting. One domain per call. Use it to qualify a prospect ('do they run Shopify?') or profile a competitor's stack.
data_seo_tech_search	Returns websites that run the given technologies (e.g. every site on Shopify plus Klaviyo), with domain rank, country and last-seen data. Turns a tech stack into a prospect list in one call. The per-row cost here is roughly 10x the keyword endpoints, so keep `limit` tight: 100 rows is a meaningful list, 1000 is an expensive pull.
agnt_credits_balance	Returns this workspace's current agntdata credit balance (purchased + subscription remaining), in cents.
agnt_usage_recent	Returns the most recent usage_logs rows for this workspace (across all data and connection calls).
agnt_usage_ai_recent	Returns recent Anthropic compute-usage rows for this workspace — the per-event ledger that powers AI credit spend (one row per `model_request_end` span or runtime tick). Each row carries `model`, `category` ('input' \| 'output' \| 'cache_read' \| 'cache_creation_5m' \| 'cache_creation_1h' \| 'tool_use' \| 'env_active_seconds'), `credits_charged` (cents — 1 credit = 1¢ = $0.01; divide by 100 for dollars), `deployed_agent_id`, and `agent_session_id`. Use this when you need event-level detail; for a windowed summary use `agnt_usage_summary` (which also returns convenient `*_usd` mirror fields).
agnt_usage_summary	Returns a windowed credit-spend breakdown for this workspace, combining AI compute (`agent_compute_usage`) and upstream data + connection calls (`usage_logs`). UNITS: every `_cents` field is integer ¢ (1 credit = 1¢ = $0.01) AND is paired with a `_usd` mirror field that is already divided by 100. WHEN DISPLAYING DOLLAR AMOUNTS TO USERS, USE THE `_usd` FIELDS DIRECTLY — do not divide `_cents` yourself (a common bug is dividing by 10,000 instead of 100, which renders dollars as ten-thousandths). Example: `totals.ai_cents = 26296.67` ⇒ `totals.ai_usd = 262.97` ⇒ render as "$262.97". A top-level `_units` block in the response restates this. Response includes: `totals` (ai/data/total in both cents and usd), `ai_by_category` (prompt / cache / runtime / other, both units), `ai_by_model` (top 10, both units + share), `data_by_provider` (top 10, both units + share), `by_agent` (per-deployed-agent split, both units), and a `daily` series (both units). Pass `bucket: 'hour'` to also get an `hourly` series (window must be <= 7 days). Pass `group_by` (1 or 2 of `day`/`hour`/`model`/`category`/`agent`/`provider`) to get a `pivot` cross-tab — e.g. `['day','model']` answers 'which model drove Tuesday's spike?', `['agent','provider']` answers 'which agent leans hardest on each data source?'. AI-only dims (`model`,`category`) cannot be combined with data-only dims (`provider`).
agnt_usage_sessions	Top deployed-agent sessions ranked by AI spend (or AI event count) in a window. UNITS: `ai_cents` is integer ¢ (1 credit = 1¢ = $0.01) and is paired with `ai_usd` (already divided by 100); USE `ai_usd` WHEN DISPLAYING DOLLAR AMOUNTS — do not divide `ai_cents` yourself. A top-level `_units` block in the response restates this. Each row returns `agent_session_id`, `deployed_agent_id`, `title`, `status`, `started_at`, `last_event_at`, `duration_ms`, `ai_cents`, `ai_usd`, `ai_event_count`, `primary_model` (the model with the most spend in this session), and `data_tool_call_count` — the count of upstream data/connection calls tagged to this session's deployed agent during [started_at, last_event_at]. Note: data-spend is not exactly attributed per session (usage_logs has no session id today); `data_tool_call_count` is a time-window proxy that signals 'how much data work happened in this session', not exact cost. Use this to answer 'which sessions blew up our spend last week?', 'is the new agent more expensive per session than the old one?'.
agnt_webhooks_send	Sends a JSON payload to one of the workspace's outbound webhook endpoints by its name or id.
agnt_webhooks_receive_recent	Returns the most recent inbound webhook deliveries received by this workspace.
agnt_webhooks_inbound_url	Returns this agent's inbound webhook endpoint URL(s) so you can give an external service a callback URL that delivers BACK INTO YOUR CURRENT SESSION. Append your own session id (provided at session start as `your_session_id`) to the `ingest_url`: `<ingest_url>/<your_session_id>`. When an external service POSTs to that URL, its payload is injected into THIS session as a new turn — hand it out as 'call me back here when the job is done' and react when the result arrives (no polling). Returns `{ endpoints: [{ id, name, ingest_url, session_url_template }] }`. If the list is empty, no inbound endpoint is bound to this agent yet — create one with `agnt_webhooks_create_endpoint` and bind it with `agnt_webhooks_link_agent` (or pass `deployed_agent_id` to `agnt_webhooks_create_endpoint` to do both in one call).
agnt_memory_remember	Writes a single durable memory to the agent's long-term store (the shared superagnt memory). State the fact in one or two sentences as `content`; it is embedded for relevance retrieval and surfaced automatically in future sessions. Near-duplicate content is deduped. Use deliberately — only persist what should survive across sessions (preferences, stable facts, commitments), never ephemeral task detail or anything recoverable from a CRM/DB. The memory lands in this agent's configured write scope (the shared workspace brain by default).
agnt_memory_recall	Returns the single most relevant memory for a natural-language query (or null). Convenience over `agnt_memory_search` when you want just the best match.
agnt_memory_search	Semantic search over the agent's readable memory (its own + the shared workspace brain). Embeds the query and returns the closest matches by relevance. Relevant memories are also auto-injected each turn, so reach for this only when you need more than what's already in context.
agnt_memory_forget	Forgets the memory that best matches `query` (preferring a verbatim content match, else the top semantic hit). Archives it — it stops surfacing but is recoverable. Returns `{ forgotten: false }` if nothing matched.
agnt_memory_recall_entity	Expands a person/company/thing the conversation is about into its full memory card — identity, current standing, open threads, identifiers, recent interactions, and linked entities. The compact stub for in-context entities is auto-injected each turn; call this only when you need the deeper history behind a stub. Look up by `entity_id` (from a stub) or by `name`.
agnt_memory_commit	Internal housekeeping (NOT visible to the user — never narrate it or echo its contents). Records the durable memory you learned THIS turn, in one structured call. Call it every turn as your LAST tool call, BEFORE writing your user-facing reply (the reply is your final message, written after this result comes back), and lean toward capturing — if anything could be useful in a future session, include it. Lanes: workspace_memories (shared business truths + standing rules), user_memories (durable facts about the operator you work for), entities (people/companies the conversation is about + soft facts — each as its OWN node; split a person from their employer rather than merging them), relations (durable structural ties only, using the plainest verb that fits — e.g. how a person relates to where they work — NOT interactions like pitched/contacted). Avoid only: system/pipeline mechanics and raw run dumps (long ID lists, full payloads). Server-side dedup applies, so when unsure, capture it.
agnt_prospect_lists	Lists the prospecting lists configured in this workspace. Each entry is a named target audience that delivers fresh leads continuously. Use this first to discover which list_id to pass to other prospecting tools.
agnt_prospect_leads	Reads leads from a prospecting list. Returns the most recently updated leads first. Use `since` (ISO timestamp) to fetch only leads updated after a known watermark, `status` to filter by pipeline stage, and `cursor` for pagination. Already-acted-on leads stay in place — change a lead's status with `agnt_prospect_update_lead` so future runs skip it.
agnt_prospect_refresh	Asks the platform to scan for new leads on a prospecting list right now. New leads stream in continuously in the background; this tool is a backstop you can call when you want a top-up on demand. Returns immediately; new leads land in the list shortly after.
agnt_prospect_update_lead	Updates the pipeline status of a single lead so other agents and the dashboard reflect that work has been done on it. Use `acted_on` after you have actioned the lead (sent an email, created a CRM record, etc.) and `discarded` for a hard-no — both prevent re-delivery on subsequent reads.
agnt_queues_enqueue	Pushes an item onto an agent queue. Each queue is bound to a deployed agent; items are processed sequentially (one fresh session per item) until the queue drains. Use this to hand work off to a sibling agent — e.g. scrape a list and call this once per item so the bound agent processes them one-at-a-time. Returns `{ item_id, queue_id, position }`. Fails if the queue is paused/archived. For many items at once, prefer `agnt_queues_enqueue_batch`.
agnt_queues_enqueue_batch	Pushes many items onto an agent queue in one call. Same semantics as `agnt_queues_enqueue` — items are appended in order and processed sequentially by the bound deployed agent. Use this when you have a list of work to hand off (e.g. enriching a batch of leads) instead of looping over `agnt_queues_enqueue`. Max 500 payloads per call. Returns `{ queue_id, items: [{ item_id, position }] }` in the order they were appended. Fails atomically (no items enqueued) if the queue is paused/archived.
agnt_data_job_submit	Submit one or more items to a data pipeline (data job) in this workspace for batch AI processing. This is the PRIMARY way to feed a pipeline: push items here and the pipeline drains them in batches — one cheap structured AI call per item — far cheaper than an agent session per item. Use this to hand a list of rows off to a pipeline (e.g. scrape leads, then submit each `{ row_id }` to the 'qualify leads' pipeline). Returns `{ data_job_id, submitted }`. Fails if the pipeline is paused/archived. Max 1000 payloads per call.
agnt_queues_list	Lists agent queues in the calling agent's workspace, newest first, with current depth counts. Use this to discover queue ids (so you can enqueue onto them) or to monitor depth (e.g. before scheduling more work). Each row includes `pending_count` (waiting to dispatch) and `processing_count` (currently running). Set `deployed_agent_id` to scope to a single bound agent. Returns `{ queues: [{ queue_id, name, description, status, concurrency, deployed_agent_id, pending_count, processing_count, created_at }] }`.
agnt_queues_list_items	Lists items in a queue, ordered by position (most recently enqueued first), with cursor pagination. Use this to inspect what's queued (`status='pending'`), what's currently running (`status='processing'`), or recent outcomes (`status='completed'` / `'failed'`). Returns `{ queue_id, items: [{ item_id, position, status, payload, error, agent_session_id, started_at, completed_at, created_at }], next_cursor }`. When `next_cursor` is non-null pass it back as `cursor` to fetch the next page.
agnt_datetime_now	Returns the current date and time. Call this whenever you need to know "now" — your system prompt only carries a static deploy date, so use this tool for anything time-sensitive: today's date, recency checks, scheduling, deadlines, or age calculations. Returns UTC plus, if a `timezone` is given, a human-readable local rendering.
slack_post_message	Posts a message into a Slack channel using the workspace's connected Slack install. Returns the channel + ts (which can be used as a thread_ts for replies).
slack_request_approval	Posts an interactive Slack message with Approve and Decline buttons, so a human can authorize (or reject) an action before you take it. IMPORTANT — this is asynchronous: this tool returns an `awaiting_human_approval` status, NOT a confirmation that anything was sent or done, and NO decision has been made when it returns. After calling this tool, END YOUR TURN — you cannot block waiting for the click, and you must NOT perform the gated action or call any other tool. When the user presses a button, THIS SAME CONVERSATION automatically resumes with a `<slack_approval_response>` turn telling you whether they approved or declined — continue (perform the action, or stand down) from there. Do NOT poll. Use this instead of `slack_post_message` whenever you need explicit human sign-off (deploys, sending an external message, spending, deletions, anything irreversible).
slack_conversation_history	Returns the most recent messages from a Slack channel (top-level, not threaded).
slack_conversation_replies	Returns the messages in a Slack thread.
slack_list_channels	Lists Slack channels (public and/or private) the workspace's bot can see. Use this to resolve a channel name (e.g. "general") to its channel id (e.g. "C0123") rather than asking the user to paste one. Returns a `channels` array of `{ id, name, is_private, is_archived, is_member, num_members, topic, purpose }` plus a `next_cursor` for pagination. The bot only sees private channels it has been invited to.
slack_get_channel_info	Fetches metadata for a single Slack channel by id: name, topic, purpose, member count, archived/private flags, and whether the bot is a member. Useful for verifying a cached channel id still resolves to the expected channel before posting.
slack_create_channel	Creates a new Slack channel in the workspace's connected install. The bot is automatically added; invite additional users with `slack_invite_to_channel`. Channel names must be lowercase, 1-80 chars, and may only contain letters, numbers, hyphens, and underscores — Slack normalizes mixed-case input automatically. Returns the new channel id and metadata.
slack_invite_to_channel	Invites one or more Slack users to a channel. Brand-new channels created via `slack_create_channel` only contain the bot — call this immediately after to add the user/team or no human will see the bot's messages. Resolve user ids first with `slack_lookup_user_by_email` (do not ask the user to paste Slack user ids).
slack_lookup_user_by_email	Looks up a Slack user in the workspace's connected install by their email address. Returns the user's Slack id, display name, and profile fields. Use this to (a) turn an email into a user id for `slack_invite_to_channel`, or (b) resolve a user for an @mention in `slack_post_message` (format: `<@U0123>`). Returns a 404-style error if no user with that email exists in the workspace.
agnt_db_status	Report the workspace database lifecycle state: `provisioning` \| `active` \| `failed`, plus readiness, region, and any provisioning error. Call this when another `agnt_db_*` tool says the database is not ready, or before heavy database work right after deployment. Safe read — never touches data; if the database was never created, calling this kicks off provisioning.
agnt_db_list_tables	List tables in the workspace database with their columns, types, and RLS status. Use this for any schema introspection — do not hand-roll `information_schema` queries. Mirrors Supabase MCP `list_tables`.
agnt_db_list_extensions	List installed Postgres extensions in the workspace database. Mirrors Supabase MCP `list_extensions`.
agnt_db_list_migrations	List migrations applied via `agnt_db_apply_migration`. Mirrors Supabase MCP `list_migrations`.
agnt_db_apply_migration	Apply a DDL migration to the workspace database. Use for `CREATE TABLE`, `ALTER TABLE ADD COLUMN`, indexes, etc. Records the migration in `supabase_migrations.schema_migrations`. New tables are auto-RLS-locked; include table grants plus explicit RLS policies when future Supabase/PostgREST-style access should work outside service-role SQL calls. For dedicated workspace agent-state tables, default to authenticated policies for the needed operations. Requires `allow_apply_migration: true` in config; destructive statements (DROP/TRUNCATE) require user confirmation. Mirrors Supabase MCP `apply_migration`.
agnt_db_execute_sql	Run a single arbitrary SQL statement against the workspace database. Use for ad-hoc reads or DML the CRUD helpers don't cover. For schema introspection (columns, types, RLS) prefer `agnt_db_list_tables`; if you still need raw `information_schema` queries, you must pass `read_only: true`. Honors per-agent `read_only`. Mirrors Supabase MCP `execute_sql`.
agnt_db_select	Read rows from a public.* table. Prefer this over execute_sql for simple reads.
agnt_db_insert	Insert one or more rows into a public.* table. By default returns `{success, affected_row_count}` to keep the response small; pass `return_rows: true` to receive the inserted rows.
agnt_db_upsert	Insert rows or update on conflict. `on_conflict` is a comma-separated list of columns that uniquely identify a row. By default returns `{success, affected_row_count}`; pass `return_rows: true` to receive the upserted rows.
agnt_db_update	Update rows in a public.* table matching `filters`. At least one filter is required to prevent accidental table-wide updates. By default returns `{success, affected_row_count}`; pass `return_rows: true` to receive the updated rows.
agnt_db_delete	Delete rows in a public.* table matching `filters`. At least one filter is required. By default returns `{success, affected_row_count}`; pass `return_rows: true` to receive the deleted rows.
agnt_db_load_csv	Stream a CSV stored in workspace_files into a public.* table. Server-side: handles parsing, type inference, batched upsert (1000 rows/batch), and dedup via `on_conflict`. Returns small counts + a capped error list — never row data — so it does not hit the response-truncation cap that breaks model-driven row-by-row loads. Prefer this over orchestrating csv_query + agnt_db_upsert in the model. Pass `create_if_missing: true` to auto-create the table from the first ~200 sampled rows (requires `allow_apply_migration: true`); pass `dry_run: true` for a parse-only preview.
agnt_files_list	List workspace files (chat uploads, skill outputs, API uploads) visible to this agent. Paginated by created_at desc; pass the returned `next_cursor` to walk older files. Optional filters narrow by source / mime prefix / name prefix.
agnt_files_get	Fetch metadata for a single workspace file by id. Returns id, file_name, mime_type, byte_size, kind, source, status, created_at, metadata. Does NOT return content — use agnt_files_read for that.
agnt_files_read	Read the contents of a workspace file. For text/CSV files, returns utf-8 text with optional line range. For binary files (images, PDFs, anything non-text), returns base64. Per-call cap of 256 KB; paginate large reads via the `offset` / `limit` fields.
agnt_files_upload	Upload a new workspace file produced by the skill (e.g. a report, an export CSV, a generated PDF). The file becomes visible to the user, to the meta-agent in a future session, and to other agents in the workspace. Bytes are passed inline; for large outputs split across multiple files.
agnt_agents_list	List the deployed agents in this workspace (id, name, draft/disabled state, model, default channel, gateway URL). Start here before any other lifecycle call — every other tool takes an `agent_id` from this list. Read-only.
agnt_agents_get	Read one agent in full: its `config` blob (system prompt, model, configured tool refs, workspace-DB policy, skills, document collections), draft/disabled state and gateway URL. Read this before patching — `agnt_agents_update_config` takes a DIFF against exactly this config. Read-only.
agnt_agents_create	Create a new agent as a DRAFT. A draft exists in the workspace but does not run and cannot receive input until `agnt_agents_deploy` is called, so this call costs nothing. Pass `name` (never "Untitled agent" — deploy refuses that name) and optionally `system_prompt` / `model`; everything else is set afterwards with `agnt_agents_update_config`. Writes to the workspace.
agnt_agents_update_config	Patch an agent's config and APPLY IT IMMEDIATELY — there is no approval card here, unlike the dashboard wizard, and a change to a deployed agent takes effect on its next session. `patch` is a compact diff (same schema the wizard validates), so send only the keys you are changing: `{ system_prompt: { set \| append } }`, `{ model: { set } }`, `{ tools: { add[], remove[] } }` (each entry a `config_ref` copied verbatim from `agnt_tools_search` — that is the ref source; `agnt_agents_get` also carries refs already on an agent — OR a bare callable tool name, which is resolved server-side when it maps to exactly one tool and rejected with the candidate refs when ambiguous), `{ workspace_db: {...} }`, `{ connections_db: {...} }`, `{ permissions: { tools: {...} } }`, `{ observability_enabled: { set } }`, `{ agent_invocation_enabled: { set } }`, `{ document_collection_ids: { add[], remove[] } }`, `{ code_execution: {...} }`, `{ native_skills: { upsert[], remove[] } }`, `{ invocation_card: { set } }`. An invalid patch returns `issues[]` with a path per problem and changes nothing.
agnt_agents_deploy	Deploy a draft agent for real. THIS IS NOT A PROPOSAL: it provisions the agent runtime, mints its gateway key and flips it live, and the agent starts consuming workspace credits from its first session. There is no approval card — confirm with the human before calling. Refuses (without partial state) when the workspace fails the deploy entitlement gate or the agent is still named "Untitled agent". Idempotent: an already-deployed agent is returned unchanged.
agnt_agents_set_enabled	Enable or disable a deployed agent. Disabling stops it responding to triggers, schedules and chat routes without tearing anything down, and is the reversible way to stop a misbehaving agent — prefer it over archiving. Applies immediately.
agnt_agents_archive	Archive an agent: archives its runtime, revokes its gateway key and removes it from the workspace listing. NOT REVERSIBLE from this surface and applies immediately with no approval card — confirm with the human first, and prefer `agnt_agents_set_enabled({ enabled: false })` when you only want it to stop responding.
agnt_connections_list	List the vendor connections this workspace has (integrations, OAuth installs and first-party connectors) with their connected state. Check this before wiring a tool that needs a vendor — a configured tool whose vendor is not connected fails at call time. Read-only.
agnt_connections_request	Ask for a vendor connection. This CANNOT connect anything on its own — OAuth and credential entry need a human — so it returns the vendor's label, auth type, current connected state and the dashboard URL to open, which you then hand to the user. Re-check with `agnt_connections_list` after they confirm. iMessage is refused here: it has no connect card, and the workspace counts as connected once a phone binding is confirmed (`agnt_bindings_add_imessage`).
agnt_bindings_list_chat_routes	List chat-platform routes (Slack channels and DMs) bound to agents in this workspace. A route with an empty `channel_id` is the workspace default — the agent that answers anywhere no channel-specific route matches. Read-only.
agnt_bindings_create_slack_route	Bind an agent to a Slack channel so messages there reach it. Requires the workspace to have connected Slack first (`agnt_connections_request` with id `slack`). Omit `channel_id` to create the WORKSPACE DEFAULT route — the catch-all for every channel with no specific route; there can only be one, so a second call for it conflicts. `reply_mode: 'mentions'` answers only when the agent is @-mentioned; the default 'all' answers every message in the channel. Applies immediately. Binding a DRAFT agent is allowed but nothing routes until it is deployed.
agnt_bindings_delete_chat_route	Delete a chat-platform route. The agent stops receiving messages from that channel immediately. Applies directly with no approval step.
agnt_bindings_imessage_settings	Whether iMessage is configured on this deployment, and the agnt phone number end-users text to activate a binding. Call this before offering an iMessage flow — on a deployment without the iMessage secrets there is nothing to bind. Read-only.
agnt_bindings_list_imessage	List iMessage phone bindings (pending and confirmed) for one agent or the whole workspace. A `pending` binding does not route yet — its owner still has to text the agnt number. Read-only.
agnt_bindings_add_imessage	Register a phone number against an agent. THIS DOES NOT FINISH THE BINDING: it creates a PENDING row and returns the agnt number plus activation instructions, and the phone's owner must text that number before anything routes. Confirm the number with the human first — it is somebody's real phone. Fails when the number is already bound to another agent here or elsewhere on the platform.
agnt_bindings_delete_imessage	Remove an iMessage binding. That phone stops reaching the agent immediately. Applies directly with no approval step.
agnt_schedules_list	List an agent's cron schedules (expression, timezone, the input text each run sends, enabled state, next run). Read-only. Use `agnt_observability_list_trigger_runs` to see whether past runs actually fired.
agnt_schedules_create	Create a cron schedule that starts a session on the agent and sends it `input_text`. THIS IS LIVE AS SOON AS IT IS CREATED (unless you pass `enabled: false`) and every firing is a billed agent run — confirm the cadence with the human. The agent must be deployed for runs to dispatch. Applies directly with no approval card.
agnt_schedules_update	Update a schedule in place — rename it, change the cron expression or timezone, rewrite the input text, or flip it on/off. The next run time is recomputed. Applies immediately.
agnt_schedules_delete	Delete a schedule. Not reversible from this surface — prefer `agnt_schedules_update({ enabled: false })` when you only want to pause it.
agnt_queues_create	Create a work queue bound to a deployed agent. Items enqueued onto it (via `agnt_queues_enqueue`) are dispatched by the cron sweep as fresh, billed agent sessions — up to `concurrency` in parallel — so the agent must be deployed for items to run. Applies immediately with no approval card. Push work onto it with `agnt_queues_enqueue`; inspect it with `agnt_queues_list` / `agnt_queues_list_items`.
agnt_queues_update	Update a queue in place — rename it, change its description or concurrency, or move its `status`. `status: "paused"` stops the sweep from dispatching new items (in-flight ones finish); `"active"` resumes; `"archived"` is a soft, TERMINAL retire (an archived queue cannot be reactivated). Prefer archive over delete when you only want to stop a queue — delete is irreversible and drops its items.
agnt_queues_delete	Permanently delete a queue. This is a HARD delete and cascades to every queued item (pending, processing, and completed) — it is not reversible from this surface. When you only want to stop a queue, use `agnt_queues_update({ status: "archived" })` (soft, keeps history) or `{ status: "paused" }` (reversible) instead.
agnt_webhooks_list_endpoints	List webhook endpoints in the workspace. Use `direction` to choose which side to return: - `inbound` (default) — endpoints that RECEIVE webhooks. Each returns id, name, description, deployed_agent_id (the bound agent, or null), data_job_id (the bound data job, or null) and the ingest URL. - `outbound` — endpoints that SEND webhooks. Each returns id, name, description, deployed_agent_id (the owning agent, or null), target_kind ('external' \| 'agent'), target_url, target_agent_id and signing_required. - `both` — returns both sets. Each endpoint carries a `direction` field so the two kinds are distinguishable. `unbound_only` applies to inbound endpoints only (outbound endpoints have no agent/data-job binding).
agnt_webhooks_create_endpoint	Create a new INBOUND webhook endpoint that will RECEIVE webhooks. WRITES DIRECTLY. Returns the ingest URL to hand to the upstream system. Optionally bind it in the same call to EITHER an agent (`deployed_agent_id`) OR a data job (`data_job_id`) — not both. Binding targets (mutually exclusive): - `deployed_agent_id` — every delivery fires the bound agent (spawns a session) and auto-acks on success. - `data_job_id` — every delivery enqueues ONE data-job queue item, with the raw JSON body as the item payload, and the pipeline drains it like any other pushed item. Use this for high-volume, non-conversational ingestion (e.g. a SaaS firing one webhook per record). Signing defaults (you should rarely need to override these): - `source_kind=external_user` → signing on (we generate an HMAC secret; use it to sign your requests). - `source_kind=agent` → signing forced on (required for agent-to-agent traffic). - `source_kind=external_integration` → signing off by default — third-party SaaS providers ship their own scheme that we don't yet implement; setting it to `agnt_hmac` will reject every delivery. The generated signing secret is returned ONCE in `signing_secret` at creation — store it now; `agnt_webhooks_rotate_secret` mints a new one if it's lost. If you bind to a draft agent, the endpoint still ingests deliveries but they will NOT fan out to the agent until it is deployed — the result includes `agent_draft: true` and a `requires_deploy` warning; deploy it with `agnt_agents_deploy`. For agent-to-agent setups: create the RECEIVING agent's endpoint with `source_kind=agent` first; when you later create the SENDING agent's outbound endpoint with `agnt_webhooks_create_outbound` and `target_kind=agent`, the dispatch layer uses the receiver's secret automatically.
agnt_webhooks_create_outbound	Create an OUTBOUND webhook endpoint that an agent can SEND payloads to via the `agnt_webhooks_send` tool. WRITES DIRECTLY. Two flavors: - `target_kind=external` — POST to an arbitrary URL (`target_url` required). Use this when the agent should notify a user-controlled system. Defaults to signing the payload with HMAC-SHA256 and returning the secret once so the receiver can verify. Opt out with `signing_mode=none`. - `target_kind=agent` — POST to a sibling deployed agent's inbound endpoint (`target_agent_id` required). Signing is FORCED ON. The receiving agent must already have an inbound endpoint with `source_kind=agent` (use `agnt_webhooks_create_endpoint` first); the dispatcher uses the receiver's signing secret automatically. Returns the endpoint id and (for newly generated keys) the signing secret. The secret is shown ONLY at creation time — call `agnt_webhooks_rotate_secret` to mint a new one. Bind the endpoint to an agent via `deployed_agent_id` so the dashboard groups outbound endpoints under their owner.
agnt_webhooks_update_outbound	Patch an existing OUTBOUND webhook endpoint in place. WRITES DIRECTLY. Use this to change the destination URL or description without recreating the endpoint (which would change its name/id and break the agent's `agnt_webhooks_send` calls). Only the fields you pass are changed. - `target_url` — only valid for `external` endpoints; must be http(s). Rejected on `agent`-targeted endpoints. - `description` — pass an empty string or null to clear it. - `signing_required` — toggle signature enforcement. Turning it ON requires an existing secret (rotate one first with `agnt_webhooks_rotate_secret`); it cannot be turned OFF on agent-to-agent endpoints (those always sign). To change the signing secret itself, use `agnt_webhooks_rotate_secret`. To enable/disable the endpoint, use `agnt_webhooks_set_active`.
agnt_webhooks_set_active	Enable or disable a webhook endpoint without deleting it. WRITES DIRECTLY. Deactivating is the soft delete used throughout — an inactive INBOUND endpoint stops ingesting (its URL returns an error) and an inactive OUTBOUND endpoint makes the agent's `agnt_webhooks_send` calls fail. Set `active: true` to restore a previously disabled endpoint. Works for both sides via `endpoint_kind`.
agnt_webhooks_rotate_secret	Generate a fresh signing secret for an inbound or outbound webhook endpoint. WRITES DIRECTLY and is destructive — the previous secret stops working immediately, so update your senders/verifiers right away. Returns the new plaintext secret (shown once).
agnt_webhooks_link_agent	Bind an existing INBOUND webhook endpoint to an agent (or pass `deployed_agent_id: null` to detach). WRITES DIRECTLY. Binding to an agent clears any data-job binding (an endpoint targets one or the other). The target agent must exist. If it is still a draft, the binding is saved but deliveries won't fan out until deploy — the result includes `agent_draft: true` and a `requires_deploy` warning; deploy it with `agnt_agents_deploy`.
agnt_webhooks_link_data_job	Bind an existing INBOUND webhook endpoint to a data job (or pass `data_job_id: null` to detach). WRITES DIRECTLY. Once bound, every delivery enqueues one data-job queue item (the raw JSON body as the payload) and the pipeline drains it. Binding to a data job clears any agent binding (an endpoint targets one or the other). The data job must already exist; if it is paused or archived, deliveries are still recorded but the enqueue is rejected and the delivery is marked failed.
agnt_webhooks_list_deliveries	Inspect the delivery audit log for webhook endpoints — every attempt that came IN to an inbound endpoint or went OUT from an outbound endpoint, newest first. This is the tool for debugging "my webhook isn't firing / the receiver is rejecting it": each row carries the dispatch outcome, the HTTP response status, the error, and the retry attempt number. Use `direction` to pick the side: - `inbound` — deliveries RECEIVED by an inbound endpoint. Each row: id, webhook_endpoint_id, dispatch_status (`pending`\|`dispatched`\|`skipped`\|`failed`), dispatch_error, agent_session_id (the session it spawned), acknowledged_at, source_ip, created_at. The raw payload + headers are returned by `agnt_webhooks_get_delivery`, not here. - `outbound` — deliveries SENT by an outbound endpoint. Each row: id, outbound_endpoint_id, deployed_agent_id (the sender), dispatch_status (`pending`\|`succeeded`\|`failed`), response_status, response_body_truncated, error, attempt (1 = first try, 2 = the one auto-retry), parent_delivery_id (the original attempt this row retried), receiving_endpoint_id/receiving_delivery_id (for agent→agent), signed, created_at, delivered_at. Filter with `endpoint_id` (scope to one endpoint) and `status` (only that outcome — e.g. `failed`). Paginate with `cursor` (pass back the returned `next_cursor`). Call `agnt_webhooks_get_delivery` with a row's id to see the full payload + headers.
agnt_webhooks_get_delivery	Fetch a SINGLE webhook delivery by id, including the heavy fields the list omits: the full request payload and headers, and (for outbound) the response body and response headers. Use this after `agnt_webhooks_list_deliveries` surfaces a failing delivery and you need to see exactly what was sent and what came back. `direction` must match the side the delivery belongs to.
agnt_knowledge_list_collections	List the workspace's document collections (id, name, chunking config, refresh schedule). Bind a collection to an agent with `agnt_agents_update_config({ document_collection_ids: { add: [id] } })` — that is what grants the agent its `agnt_documents_*` tools. Read-only.
agnt_knowledge_create_collection	Create a document collection — the retrieval unit an agent is bound to. Chunking defaults (512 tokens / 64 overlap) suit prose; raise the chunk size for reference tables and dense technical docs. `refresh_schedule` controls whether URL/integration documents are re-fetched automatically.
agnt_knowledge_list_documents	List the documents in a collection with their indexing status (`pending`, `indexing`, `ready`, `error`) and last error. This is the poll target after adding a document — a collection is only searchable for documents that reached `ready`. Read-only.
agnt_knowledge_add_document	Add a source document to a collection and start indexing it. RETURNS BEFORE INDEXING FINISHES — the document comes back in `indexing` state and you must poll `agnt_knowledge_list_documents` until its status is `ready` (or `error`) before searching or telling the user the knowledge base is live. `kind: 'url'` needs `config.url`; `kind: 'file'` needs `workspace_file_id` from `agnt_files_upload`. Indexing consumes embedding credits.
agnt_knowledge_ingest	Re-index a document that already exists in a collection (a source changed, or a previous run left it in `error`). Same async contract as adding one: this returns immediately with the document in `indexing` state — poll `agnt_knowledge_list_documents` for `ready`. Consumes embedding credits.
agnt_knowledge_search	Semantic search over one collection, returning the best-matching chunks with their source document and similarity. Use it to verify a freshly-ingested collection actually answers the questions the agent will be asked, before wiring it onto the agent. Read-only (embeds the query, which consumes a small amount of credit).
agnt_guidance_load	Load one of the platform's curated guidance skills — the same corpus the dashboard wizard reads before designing or building. A bare call returns the skill's body (which names its reference sections when it has any); pass `section` for one reference file. CALL THIS BEFORE building in a skill's domain — the bodies encode the sequence, the pitfalls, and the shape that works, authored by the platform rather than inferred. The catalog: - `canvas-dashboards` — Design and build live canvas dashboards over the workspace database — widget selection, layout, color, SQL bindings. Load BEFORE creating or editing any canvas or widget. - `typescript-sdk` — The TypeScript SDK for skills and data jobs — what agnt.* exposes (data, connections, db, runtime, ai, utilities, anthropic, errors) and the tool-naming rules. Load before writing or reviewing any TypeScript skill code. - `typescript-skills` — How to author, validate, and ship a TypeScript skill or data-job recipe — the dry-run loop, never-deploy-red, runtime tool coverage, and repairing deployed pipelines. Load before writing, attaching, or fixing any TypeScript skill. - `workspace-db-design` — Schema patterns for agent state in the workspace database — dedup tables, pipeline status, review queues, KPI event tables, audit rows — designed so canvases can chart them. Load when designing tables for any agent that runs on schedules, webhooks, or multi-step pipelines. - `data-pipelines` — Data-processing jobs over many rows — AI and non-AI — with data jobs. When to use a data job vs a sub-agent vs a queue, the agnt.ai batch helpers, per-row tools, and the build flow. Load when the task is "apply the same operation to a whole table" or "process this CSV/export at row scale". - `lead-generation` — Design lead scraping and lead-gen agents — dedup, the leads table, batch scraping via data jobs, source selection, failure handling, honest reporting. Load when building anything that scrapes, enriches, or scores leads. - `email-triage` — How inbox management works — triage rules (deterministic + AI), the Inbox Manager intake layer, enablement flow, and wiring Gmail/Outlook mailbox tools into any agent, including send-permission defaults. Load for anything touching email routing, inbox rules, or mailbox tools. - `imessage-agents` — Build agents that talk over iMessage — availability check, plain-text conversational prompt design, deploy, phone bindings and the text-first activation flow, plus every edge case (409s, expiry, group chats). Load when an agent should send or receive texts. - `agent-teams` — When and how to group collaborating agents into teams — reuse by name, assign on build, ungroup. Load when building or organizing multiple agents that work together. Bodies name the dashboard wizard's tool names; the response carries a `tool_name_mapping` to this surface's equivalents. Read-only.
agnt_guidance_search	Search the platform's canonical build-guidance skills by keyword and get back the matching catalog entries plus the best match's body. Prefer `agnt_guidance_load` with a skill name from its catalog — this search is a compatibility adapter over the same corpus. Read-only.
agnt_guidance_build_instructions	The platform's own build doctrine, served from the same sources the dashboard wizard reads: the situational rules in the guidance registry (which vendor surface to prefer, when a script is unnecessary, migration checklists, dry-run sampling, model selection, …) plus the always-on topic sections of the wizard system prompt (live-API safety, billing and deploy gates, post-deploy smoke tests). The former email_triage / imessage / agent_teams topics now live in the skill corpus — fetch them here for compatibility or via `agnt_guidance_load`. Read the relevant topic before wiring that surface — these encode failure modes that are not obvious from the tool schemas. Read-only.
agnt_sdk_docs	The `agntdata` TypeScript SDK reference — the API a TypeScript skill running inside a deployed agent uses to call tools, read/write the workspace DB, and handle errors. Read this before authoring skill code for an agent; it answers from the same source as the `typescript-sdk` skill in `agnt_guidance_load`. Pass a `query` to be routed to the right section automatically. Read-only.
agnt_typescript_skill_dry_run	Compile and execute a TypeScript skill/data-job recipe in agntdata's external Node sandbox with scoped agntdata credentials and tracked Anthropic SDK access. Runs `pnpm install`, `tsc --noEmit`, then `node dist/skill.js`. Returns either `{ ok, status:'completed', job_id, validated_code_id?, exit_code, stdout_tail, stderr_tail, ... }` when the run finishes within ~90s, or `{ status:'pending', job_id }` when it takes longer — in which case do NOT call this tool again; poll `agnt_typescript_skill_status` with the returned `job_id` until status flips to `completed`/`timed_out`. On a GREEN run (`ok:true`) the response carries a `validated_code_id`: pass it to agnt_data_job_create / agnt_data_job_update or to an agnt_agents_update_config `typescript_skills` upsert to deploy the exact validated bytes by id (source is never re-emitted, so it can't be corrupted). On a RED run, read the diagnostics via agnt_typescript_skill_status (mode 'diagnostics'/'around_error'), fix the code, and dry-run again — no handle is minted until green.
agnt_typescript_skill_status	Poll the status and tail logs of a TypeScript skill run started by `agnt_typescript_run_skill`. Use this when the run tool returned `{ status: 'pending', job_id }`. The server long-polls: each call holds for up to `wait_seconds` (default 30, max 60) and returns immediately when status flips to `completed`/`timed_out`. Do NOT immediately re-call after a pending response — that wastes tokens. Call once with `wait_seconds: 60`, then call again only when that returns. Each call also returns recent stdout/stderr lines so you can see live progress. Modes: `tail` (default — last lines), `head` (first lines), `around_error` (±10 lines around the first error), `diagnostics` (parsed tsc errors or runtime stack with relevant SDK signatures). Do NOT call `agnt_typescript_run_skill` again — that would start a fresh run.
agnt_data_job_list	List the workspace's data jobs (newest first). Each job carries its most recent run (`latest_run`: status + rows_total/done/failed), a `runs_summary` rollup across its retained runs (last ~30d) — `{ runs, rows_done, rows_failed, success_rate, avg_duration_ms, runs_completed, runs_partial, runs_failed, recent }` — AND a `queue` block of LIVE inbox/drain health: `{ pending, processing, oldest_pending_age_s, active_runs, stalled, stall_reason }`. CHECK `queue.stalled`: run history can look healthy (every run `completed`) while a wall of items sits `pending` because the drain isn't running; `stalled:true` with `stall_reason:'no_active_drain'` or `'job_paused'` is that freeze. Read-only — use to discover jobs before creating a duplicate, to check whether a run finished, to see throughput/failure rate, or to spot a stuck pipeline. Returns `{ data_jobs: [{ data_job_id, name, status, model, chunk_size, concurrency, latest_run, runs_summary, queue }] }`.
agnt_data_job_read	Read a data job's full definition — including its complete, untruncated recipe `code` (the per-item skill source) — to DIAGNOSE or repair it. This is the tool that enables the MCP repair flow: read the recipe, edit it yourself, dry-run it with agnt_typescript_skill_dry_run, then deploy the returned `validated_code_id` via agnt_data_job_update. Read-only, by `data_job_id`. Returns `{ data_job_id, name, description, status, model, chunk_size, concurrency, code, tools, write_back, params, queue }`: `code` is the per-item recipe source; `tools` is the per-job runtime-tool allowlist; `params` is the static params each batch receives; `queue` is live inbox/drain health (`{ pending, processing, done, failed, oldest_pending_age_s, active_runs, stalled, stall_reason }`) — check `queue.stalled` to see if the inbox is frozen. For per-reason failure detail use agnt_data_job_inspect_run.
agnt_data_job_create	Create a data job: a non-agentic batch pipeline that runs one cheap structured Claude call per item — the right tool to qualify / classify / enrich / extract across MANY items. WRITES DIRECTLY (workspace-scoped). Producers PUSH items onto the inbox (agnt_data_job_submit / agnt_data_job_backfill) and the pipeline batch-drains them: the recipe reads `{ items: [{ id, payload }] }` from stdin and prints `{ results: [{ id, status, result? }] }`. ALWAYS pass `validated_code_id` — the id returned by a GREEN agnt_typescript_skill_dry_run — so the server resolves the VALIDATED recipe bytes by id; never hand-write or paste recipe code (re-emitting source corrupts it). Confirm with the user before creating — runs bill credits. `chunk_size` = items per drained batch, `concurrency` = parallel batches. Returns `{ data_job_id, name, status, chunk_size, concurrency }`.
agnt_data_job_update	Update a data job's name/description/status or its config (recipe, tools, model, chunk_size, concurrency). WRITES DIRECTLY. Set `status:'paused'` to stop the pipeline draining its inbox; `'archived'` is terminal. To change the RECIPE: edit it, dry-run it with agnt_typescript_skill_dry_run, then call this with the returned `validated_code_id` — the server resolves the validated bytes by id. Never paste recipe code. Omit `validated_code_id` for a metadata/tools-only update (the recipe is left unchanged). `tools` REPLACES the per-job allowlist wholesale.
agnt_data_job_delete	Permanently DELETE a data job and CASCADE-delete all of its runs and queued/in-flight inbox items. WRITES DIRECTLY and is IRREVERSIBLE — no undo, the queue history is gone. Confirm with the user first. Prefer agnt_data_job_update({ status:'paused' }) to merely stop a pipeline draining, or `'archived'` for a terminal-but-retained state; only delete to remove a job entirely. Returns `{ data_job_id, deleted: true }`.
agnt_data_job_inspect_run	Inspect a data-job run AND the whole pipeline to debug FAILURES or a frozen inbox. Read-only. Call this when agnt_data_job_list shows a run `failed`/`partial` OR `queue.stalled` is true. Pass `run_id` for a specific run, or just `data_job_id` for the latest run (works even if the pipeline has pending items but no run yet). Returns `{ run: { status, rows_total/done/failed, error, … } \| null, logs: { stdout, stderr }, failed_items: [{ id, error, payload }], pipeline }`. `pipeline` is the whole-pipeline rollup incl. `failures_by_reason: [{ reason, count, sample_error, sample_item_ids }]` — grouped by error class so one read explains a spread-out failure — and a live `queue` block with `stalled`/`stall_reason`.
agnt_data_job_backfill	Seed a data job from EXISTING workspace-DB rows: select rows matching a table+filters (or a read-only SQL query) and push one `{ row_id }` item per row onto the pipeline inbox. Use this to backfill a pipeline over rows already in the DB, or to test-fire over real rows. WRITES DIRECTLY + bills credits over every matched row — confirm scope with the user first. Capped at 5000 rows (`truncated:true` when hit — narrow the filter and call again). The recipe must read each item's `payload.row_id` and `agnt.db.select` it. Returns `{ data_job_id, submitted, truncated }`.
agnt_observability_list_agents	List deployed agents in the workspace (id, name, draft state, model, tool counts). Use this to enumerate agents before calling the other observability tools to inspect them.
agnt_observability_list_sessions	Lists recent live sessions for a deployed agent (status, timestamps, linked trigger metadata). Read-only.
agnt_observability_search_sessions	Searches recent live sessions by free-text query, status, tool name, or "problematic only" (sessions that hit `session.error` or `is_error: true` tool results). Read-only.
agnt_observability_read_session	Inspects one deployed-agent session progressively. Default call returns a compact per-event index (position, time, type, tool, size, ERR flag, event id) plus session stats, with error events expanded inline — start here. Then drill down: `query` greps all event bodies server-side; `event_ids` fetches full payloads for specific events; `before_event_id` pages the index into older history. Read-only.
agnt_observability_list_trigger_runs	Lists recent schedule/webhook invocations for a deployed agent (dispatch status, linked live session id, errors). Read-only.
agnt_observability_get_session_usage	Summarizes Anthropic/runtime compute usage and credits for a live session or deployed agent (rows, totals, by-category breakdown). Read-only.
agnt_observability_list_escalations	Lists recent blocking human-in-the-loop requests (gated tool-call approvals and escalated questions) for a deployed agent or a specific live session. Read-only.
agnt_observability_get_diagnostics	Compact health report for a deployed agent: deploy/runtime ids, draft/disabled state, dependency checks, recent sessions, trigger failures, escalations, usage, and open runtime config requests. Read-only.
agnt_observability_check_dependencies	Checks whether a deployed agent has the runtime prerequisites implied by its config: deployment ids, disabled/draft state, integrations, connectors, remote MCP connections, workspace DB, and code execution. Read-only.
agnt_observability_read_config_request	Fetches a deployed-agent config-change request plus linked live session context so the caller can verify symptoms before acting on it. Read-only.
agnt_agents_dispatch	Delegate a task to another deployed agent in this workspace — fire-and-forget, no polling. Provide the target `agent_id` and the `message` (the full task + any data the sub-agent needs; it does not see your session). This returns immediately with `{ sub_session_id, deployed_agent_id, callback_session_id }`; finish your turn normally while the sub-agent runs in the background. By default the hand-off is ONE-WAY: the sub-agent's output does NOT come back to you — prefer this whenever you don't need to act on the result (hand-offs, notifications, pipeline stages). Only if you must consume the result to keep going, also pass `callback_session_id` set to your own runtime session id (given to you at session start as `your_session_id`); the sub-agent's final output then arrives in your session as a new `[sub_agent_result] ... status=completed` turn (or `status=failed`) — react to it then. NOTE for external MCP clients: `callback_session_id` requires YOUR OWN runtime session id, which an external client holding a workspace MCP bearer does not have — so the callback is only usable by a deployed agent calling from inside its own runtime session, and this tool is effectively fire-and-forget over MCP. For an INTERACTIVE, multi-turn, or post-deploy smoke-test probe where you need the result synchronously, use the session trio instead — `agnt_agents_session_start` / `agnt_agents_session_send` / `agnt_agents_session_poll` — which starts a real session you can drive and poll to completion. The target must be a different, deployed, enabled agent. Each sub-agent run bills to the workspace under the target agent.
agnt_agents_session_start	Start a brand-new live session with a deployed agent in this workspace so you can drive it interactively — the multi-turn, synchronous counterpart to `agnt_agents_dispatch` (which is fire-and-forget). Use this for a post-deploy smoke test, an end-to-end behavior probe, or any case where you need to send a message, wait for the agent to finish, read what it did, and follow up. Provide the target `agent_id` (must be a deployed, enabled agent — a draft or disabled agent is rejected) and optionally a `title` and an `initial_message` to send immediately. Returns `{ session_id, deployed_agent_id, title, status }`. Then poll with `agnt_agents_session_poll` until `status` is `idle`, send follow-ups with `agnt_agents_session_send`, and read the full transcript with `agnt_observability_read_session`. IMPORTANT — reading the transcript lives in a SEPARATE, opt-in family: `agnt_observability_read_session` is part of the `observability` family, which must be enabled on this workspace MCP server independently of this one; these session tools only return status, never the message payload. COST: this starts a real agent session that bills agent compute to the workspace exactly like any other session — every message you send runs the agent and costs credits.
agnt_agents_session_send	Send a user message into an existing agent live session (one you started with `agnt_agents_session_start`, or any other session in this workspace). The agent responds asynchronously — poll with `agnt_agents_session_poll` until `status` is `idle`, then read the transcript with `agnt_observability_read_session`. Reading the transcript lives in a SEPARATE, opt-in family: `agnt_observability_read_session` belongs to the `observability` family, which must be enabled on this workspace MCP server independently of this one; this tool returns no message payload. Each message runs the agent and bills agent compute to the workspace.
agnt_agents_session_poll	Long-poll the status of an agent live session. Returns STATUS ONLY — `{ id, status, last_event_at, title, deployed_agent_id }` with no event payload; `status` is one of `idle`, `running`, `archived`. By default the call holds for up to 30s while the session is still `running`, returning as soon as the status flips to `idle`/`archived` (or when the wait elapses), so you can sit in a tight `while (status === 'running')` loop without hammering the API. Pass `wait_seconds: 0` for an immediate, non-blocking read; the cap is 60s. To read the actual conversation transcript, switch to `agnt_observability_read_session` — it lives in the SEPARATE, opt-in `observability` family, which must be enabled on this workspace MCP server independently of this one; this poll tool never returns message content.
agnt_canvas_share_create	Mint a public, read-only share link for a canvas. Returns the share id and the full public URL — the URL is shown only in this response. Anyone with the link can VIEW the canvas (no editing, no workspace access) until it is revoked.
agnt_canvas_share_list	List a workspace's canvas share links (id, canvas id, label, token prefix, created / last-accessed / revoked timestamps). Never returns the raw token. Read-only.
agnt_canvas_share_revoke	Revoke a canvas share link by id. The public link stops resolving immediately (viewers get a "no longer available" page). Idempotent.
agnt_canvas_introspect_schema	List the workspace database's tables and columns so you can write widget SQL. Read-only.
agnt_canvas_preview_query	Run a candidate widget SQL read-only and return its columns + up to 50 rows. Runs through the read-only guard (statement timeout, row cap, SELECT-only).
agnt_canvas_put_widget	Add (or replace by id) a widget on a canvas. The config columns are validated against a fresh query preview and the binding is dry-run before saving; on rejection you get field-level hints. Refuses past the widget/size caps with a prune hint. VISUALIZATION CONTRACT — the exact `visualization.config` shape for every `visualization.type`. Use these EXACT key names: the top source of put_widget validation errors is inventing keys (`valueField` for `valueColumn`, `xColumn`/`yColumns` instead of the real keys) or passing a `columns` list as strings when it takes objects. A `key:` line is required; `key?:` is optional. Column-role values are RESULT COLUMN NAMES returned by your widget SQL. Layout: every widget carries `layout` with integer x,y,w,h on a 12-column grid (grid.cols = 12). Keep `x + w <= 12` (a wider tile is rejected); y and h grow downward and overlapping positions are auto-packed downward, so a safe default like `{x:0,y:0}` (with your chosen w,h) always works. ### big_value (Big value) One hero reading taken from the first row of the result — a headline KPI with an optional delta chip and an optional inline sparkline. Use for totals, counts, MRR, rates. SQL: return one row; the value column holds the figure, an optional delta column a signed percentage. config: - valueColumn: string — a result column name (number/string); Result column holding the headline value (first row). - label?: string - sublabel?: string - format?: "number" \| "compact" \| "currency" \| "percent" \| "duration_ms" - deltaColumn?: string — a result column name (number); Optional column with a percentage delta. - sparkColumn?: string — a result column name (number); Optional numeric column drawn as a sparkline trend. example prompt: show total revenue this month ### stat_group (Stat group) A compact block of label/value stats taken from the columns of the first result row — one aggregate per column. Use for a small cluster of KPIs that share a query (e.g. total, open, closed on one line). SQL: return ONE row whose columns are the metrics; name each item's `column` after a result column. config: - title?: string - items: { column, label, format?, tone? }[] — result column names (any); One entry per stat; each `column` names a column of the first row. example prompt: leads scraped, qualified, and contacted this week ### measure_list (Measure list) A vertical list of label/value rows, one per result row. Use for a ranked or named set of measures (e.g. spend by vendor, count by status). SQL: one row per measure — a label column and a value column, ordered as you want them listed. config: - title?: string - labelColumn: string — a result column name (string/time/number); Column naming each row (left side). - valueColumn: string — a result column name (number/string); Column holding each row's reading (right side). - format?: "number" \| "compact" \| "currency" \| "percent" \| "duration_ms" - toneColumn?: string — a result column name (string); Optional column of tone tokens (accent/success/warn/danger/muted). example prompt: spend by vendor this month ### trend (Trend) A trend over an ordered X axis (usually time): one or more numeric series drawn as lines/areas. Use for daily active users, revenue over time, cumulative volume. SQL: one row per X point ordered ascending; each series is its own numeric column. config: - xColumn: string — a result column name (time/string/number); Ordered X axis column (a date/time or sequence). - yColumns: string[] — result column names (number); One or more numeric columns plotted as trend series. - valueFormat?: "number" \| "compact" \| "currency" \| "percent" \| "duration_ms" example prompt: daily active users over the last 30 days ### stacked_bar (Stacked bar) Categorical bars: one bar per category row, one or more value series stacked (or grouped) within each bar. Use for composition-by-category and top-N rankings. SQL: one row per category; each series is its own numeric column. config: - categoryColumn: string — a result column name (string/time/number); Column whose distinct values label each bar group. - valueColumns: string[] — result column names (number); One or more numeric columns plotted as bar segments. - orientation?: "vertical" \| "horizontal" - stacked?: boolean - valueFormat?: "number" \| "compact" \| "currency" \| "percent" example prompt: revenue by plan tier ### combo (Combo (bar + line)) Bars for a volume measure with a line for a rate measure over the same categories. Use when a count and a ratio share an axis (e.g. sends per week with reply rate). SQL: one row per category with a bar (volume) column and a line (rate) column. config: - labelColumn: string — a result column name (string/time); Category label per bar/point. - barColumn: string — a result column name (number); Numeric column drawn as bars (volume). - lineColumn: string — a result column name (number); Numeric column drawn as the line (rate). - barLabel?: string - lineLabel?: string - barFormat?: "number" \| "compact" \| "currency" \| "percent" - lineFormat?: "number" \| "compact" \| "currency" \| "percent" example prompt: weekly sends with reply rate overlaid ### funnel (Funnel) Ordered conversion funnel. Each result row is a stage with a count; rows must already be ordered from widest to narrowest stage. Use for signup → active → paying style flows. config: - stageColumn: string — a result column name (string); Column naming each funnel stage (rows pre-ordered). - valueColumn: string — a result column name (number); Numeric count for each stage. - valueFormat?: "number" \| "compact" \| "currency" \| "percent" example prompt: funnel from signups to active to paying ### table (Table) A sortable table of rows. Use for rankings, lists, and any multi-column tabular result (e.g. top customers, recent orders). config: - columns?: { key, label, align?, format? }[] — result column names (any); Optional explicit column list; omit to render every result column. - pageSize?: number example prompt: list the top 20 customers by spend ### matrix (Matrix) A dense numeric grid — one labelled row per result row and one column per measure, with optional row totals and a highlighted max cell. Use for pivot-style breakdowns (e.g. campaign × outcome counts). SQL: one row per row-label; each measure is its own numeric column. config: - rowHeader?: string - rowLabelColumn: string — a result column name (string/time/number); Column labelling each matrix row. - valueColumns: { column, label, tone? }[] — result column names (number); One entry per column; each `column` is a numeric measure. - totals?: boolean - highlightMax?: boolean example prompt: campaign by outcome counts ### pie (Pie / donut) Pie or donut chart of a single value broken down by a label column. Use for composition of a whole (e.g. revenue share by plan). config: - labelColumn: string — a result column name (string); Column whose distinct values label each slice. - valueColumn: string — a result column name (number); Numeric column sized as the slice value. - donut?: boolean - valueFormat?: "number" \| "compact" \| "currency" \| "percent" example prompt: share of revenue by plan tier ### kanban (Kanban board) A board of status columns with one card per result row, grouped by a status column. Use for pipeline / workflow state (e.g. leads by stage, tasks by status). SQL: one row per entity with a group column (the column key), a title, and optional assignee/meta/chip columns. config: - groupColumn: string — a result column name (string); Column whose value routes each card to a board column. - idColumn: string — a result column name (string/number); Stable card id column. - titleColumn: string — a result column name (string); Card title column. - assigneeColumn?: string — a result column name (string); Optional assignee (initials) column. - metaColumn?: string — a result column name (any); Optional right-hand meta column. - chipColumns?: string[] — result column names (string); Optional columns rendered as card chips. - columns?: { key, title, tone? }[] example prompt: leads grouped by pipeline stage ### progress (Progress meter) A horizontal meter of a single 0..1 fraction, with an optional target tick and a free-form display (e.g. '124 / 200'). Use for budget used, SLA attainment, quota progress. SQL: return ONE row; the value column is a fraction between 0 and 1. config: - label?: string - valueColumn: string — a result column name (number); 0..1 fill fraction (first row). - displayColumn?: string — a result column name (any); Optional right-hand display value. - targetColumn?: string — a result column name (number); Optional 0..1 target tick. - tone?: "accent" \| "success" \| "warn" \| "danger" \| "neutral" example prompt: percent of daily send budget used ### activity_feed (Activity feed) A timestamped event stream, newest first, one row per result row. Use for audit logs, recent actions, outreach history. SQL: one row per event with a time column, a text column, and optional meta/tone columns; order by time descending. config: - timeColumn: string — a result column name (time/string); Timestamp column shown on the left. - textColumn: string — a result column name (string); Event message column. - metaColumn?: string — a result column name (any); Optional right-hand meta (e.g. source system). - toneColumn?: string — a result column name (string); Optional tone tokens (accent/success/warn/danger/neutral). example prompt: recent agent actions ### content_list (Content list) A stack of prose cards — full text preserved, not truncated to a cell. Use for drafts, notes, generated copy, summaries. SQL: one row per card with a body column (the prose) and optional title/eyebrow/meta columns; chip columns render as tags. config: - bodyColumn: string — a result column name (string); Prose body column (whitespace preserved). - titleColumn?: string — a result column name (string); Optional card title column. - eyebrowColumn?: string — a result column name (any); Optional small eyebrow label column. - metaColumn?: string — a result column name (any); Optional right-hand meta column. - chipColumns?: string[] — result column names (string); Optional columns rendered as chips. example prompt: latest content drafts with status ### record_detail (Record detail) A single entity's detail card: a title/subtitle header and a labelled field grid, all from the first result row. Use as a drill target for a lead, account, or ticket. SQL: return ONE row; the title column is the record name and each field's `column` names a column of that row. config: - titleColumn: string — a result column name (string); Record title column (first row). - subtitleColumn?: string — a result column name (any); Optional subtitle column. - avatarColumn?: string - readoutColumn?: string - fields: { column, label, tone? }[] — result column names (any); One entry per field; each `column` names a result column. example prompt: detail for one lead ### heatmap_calendar (Calendar heatmap) A day-by-day intensity grid (GitHub-style) over the last N weeks. Use for daily activity/cadence (runs per day, messages per day). SQL: one row per DAY with a date column (a `date`/`YYYY-MM-DD`) and a numeric intensity column; use `date_trunc('day', ...)` + `generate_series` if you want zero-filled gaps. Missing days render as empty. config: - dateColumn: string — a result column name (time/string); One date per row (day granularity). - valueColumn: string — a result column name (number); Intensity value for that day. - valueLabel?: string - weeks?: number example prompt: runs per day over the last 6 months ### calendar_month (Calendar month) A single-month calendar with labelled entries per day. Use for scheduled items (sends, meetings, deadlines) within a month. SQL: one row per entry with a date column (a `date`) and a label column; frame the month with `date_trunc('month', ...)` or a `generate_series` of days. Up to two entries show per cell; the rest collapse to a count. config: - dateColumn: string — a result column name (time/string); Entry date (day granularity). - labelColumn: string — a result column name (string); Entry label shown in the day cell. - toneColumn?: string — a result column name (string); Optional per-entry tone token. example prompt: scheduled sends this month ### gantt (Gantt timeline) A timeline of dated bars, one per result row, with optional progress fill and status. Use for schedules, campaigns, projects with a start and end. SQL: one row per item with a label, a `start` date column and an `end` date column (alias them clearly), plus optional progress (0..1), status, and tone columns. config: - idColumn?: string - labelColumn: string — a result column name (string); Row label shown in the timeline rail. - startColumn: string — a result column name (time/string); Bar start date (alias `start`). - endColumn: string — a result column name (time/string); Bar end date (alias `end`). - progressColumn?: string — a result column name (number); Optional 0..1 progress fill. - statusColumn?: string — a result column name (string); Optional status label in the rail. - toneColumn?: string — a result column name (string); Optional per-bar tone token. - zoom?: "month" \| "quarter" \| "year" example prompt: campaign schedule with start and end dates ### forecast (Forecast / burn-up) A burn-up: cumulative completed (`done`) rising toward a total (`scope`) over time, with an optional projection band (mid/low/high). Use for progress-to-goal with a deadline. SQL: one row per date. For the actuals use `SUM(...) OVER (ORDER BY day)` to make `done` cumulative and carry `scope` as the (constant) total; for the projection, UNION rows carrying mid/low/high and a phase marker. Rows with a non-null mid feed the forecast band. config: - dateColumn: string — a result column name (time/string); Ordered date column. - scopeColumn: string — a result column name (number); Total scope line (usually constant). - doneColumn: string — a result column name (number); Cumulative completed (SUM OVER ORDER BY day). - midColumn?: string — a result column name (number); Optional projection midline. - lowColumn?: string — a result column name (number); Optional projection lower bound. - highColumn?: string — a result column name (number); Optional projection upper bound. example prompt: cumulative leads qualified vs target with projection ### dot_strip (Dot strip) A strip of individual dots grouped by period — shows the spread of a measure (e.g. per-item durations) instead of collapsing to a mean. Use for latency/duration distributions over time. SQL: one row per ITEM with a group/period column and a numeric value column; for durations compute `EXTRACT(EPOCH FROM (finished - started))` and bucket by period. Optional series column colours the dots. config: - groupColumn: string — a result column name (string/time); Period/category each dot belongs to. - valueColumn: string — a result column name (number); The measured value for each item (dot height). - seriesColumn?: string — a result column name (number/string); Optional series index/label to colour dots. - pointLabelColumn?: string — a result column name (any); Optional per-dot hover label. - valueLabel?: string - scale?: "linear" \| "log" - valueFormat?: "number" \| "compact" \| "duration_ms" \| "percent" example prompt: per-run duration by day ### compare (Compare pair) Two tiles side by side for an A-vs-B contrast, taken from the first two result rows (row 0 = left, row 1 = right). Use for before/after, yours/theirs, staged/server diffs. SQL: return exactly TWO rows with a title column and optional eyebrow/meta columns. config: - titleColumn: string — a result column name (string); Tile title (one per row; first two rows used). - eyebrowColumn?: string — a result column name (any); Optional small eyebrow label. - metaColumn?: string — a result column name (any); Optional meta line under the title. example prompt: staged record vs server record ### checklist (Checklist) A checklist of task rows, each shown done or not-done. Use for readiness, onboarding steps, launch gates. SQL: one row per task with a text column and a boolean `done` column (0/1 or true/false), plus an optional meta column. config: - textColumn: string — a result column name (string); Task text column. - doneColumn: string — a result column name (boolean/number); Completion flag (boolean or 0/1). - metaColumn?: string — a result column name (any); Optional right-hand meta column. example prompt: launch readiness checklist ### waterfall (Waterfall) A bridge chart: an opening balance, then signed step deltas (gains positive, losses negative) summing to an end total. Use for MRR movement, headcount change, balance reconciliation. SQL: the FIRST row is the opening balance; each subsequent row is one signed delta with a label and a (positive or negative) value column. config: - labelColumn: string — a result column name (string); Step label (first row = opening balance). - valueColumn: string — a result column name (number); Opening value (first row) then signed step deltas. - endLabel?: string - valueFormat?: "number" \| "compact" \| "currency" \| "percent" example prompt: MRR bridge: starting, new, expansion, churn, ending ### approvals (Approvals) A list of pending approval cards with approve/decline actions. Bind it to a WORKSPACE-DB table your agent maintains that mirrors pending approvals — one row per pending item — NOT the platform `agent_tool_call_approvals` table (canvas SQL runs read-only against the workspace DB and cannot reach it). Required columns: an id column holding the PLATFORM approval id (this is what the approve/decline buttons resolve), a title, the body (what the agent wants to do), and optional context/meta columns. Keep the mirror current: your agent should delete or flag each row (or the query should filter to pending) once its approval resolves. config: - idColumn: string — a result column name (string); The PLATFORM agent_tool_call_approvals row id, carried in your workspace-DB mirror row (drives the approve/decline buttons). - titleColumn: string — a result column name (string); Card title. - bodyColumn: string — a result column name (string); What the agent proposes to do. - contextColumn?: string — a result column name (any); Optional context line. - metaColumn?: string — a result column name (any); Optional meta (e.g. age). - approveLabel?: string - declineLabel?: string example prompt: select approval_id, title, summary as body from pending_approvals where status = 'pending'
agnt_canvas_update_widget	Replace an existing widget (by widget_id) with a new WidgetSpec, keeping its id stable. Same validation + dry-run + hints as put_widget.
agnt_canvas_remove_widget	Remove a widget from a canvas by id.
agnt_canvas_set_layout	Set the grid layout of existing widgets. layout is a list of { widget_id, x, y, w, h } in 12-column grid units.
agnt_canvas_get	Read back a canvas (id, name, description, full DashboardSpec) to inspect current widgets before editing.
agnt_canvas_snapshot	Render a PNG image of a canvas (or a single widget on it) at a viewport preset. Returns a durable, shareable image URL you can send to Slack/email AND the image itself so you can visually inspect the layout and iterate. Read-only — the canvas is not modified.
agnt_canvas_chart_render	Render a one-off chart from a widget spec plus EITHER inline `rows` (an array of row objects) OR the widget's own workspace_sql binding (run read-only through the same guard + audit as canvas queries). Persists NOTHING — no canvas is created. Returns a durable image URL AND the image itself.

纠错与举报（发现条目失效、署名有误或涉及侵权？）

提交举报 / 纠错

侵权举报经核验成立后，我们会即时下线该条目并删除已存的内容副本。