LinkedIn data for AI agents: structured profiles, people search, companies, and posts over MCP or REST. 500 free credits, no card.
Scored across 17 tools
Tools are grouped by platform (LinkedIn, Reddit, X) and each has a distinct purpose: search, fetch profile/company, fetch posts, resolve URL, and utility (get_usage). Even across platforms, the search tools operate on different datasets, so there is no ambiguity.
All tools follow the pattern `[platform]_[verb]_[noun]` (e.g., linkedin_get_company, reddit_search, x_get_tweets). The only exception, get_usage, is a global utility and does not cause confusion.
With 17 tools covering three major social platforms, the count is well-scoped. Each platform gets roughly 5-6 tools covering search, profile, posts, and URL resolution, and the billing utility earns its place.
For each platform, the core read operations are covered: search, fetch individual items, fetch lists, and resolve URLs. There are no obvious dead ends, and the inclusion of get_usage for budget management fills the practical gap of monitoring costs.
Check your balance, plan, limits, and the last 10 charges (receipt ids included). Costs 0 credits and is exempt from the per-minute rate limit, so call it first to check your budget before running data tools, and any time after. Works the same on a trial key, a paid key, or an OAuth-connected account. The response includes upgrade_url (give it to your human when credits or plan limits block you; purchases credit this account directly with no login) and manage_url (give it to your human to change or cancel a paid plan in the Stripe billing portal). Trial accounts also get a claim_url that attaches an email so the account can be recovered if the key is lost. Not for fetching platform data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses zero cost, rate limit exemption, consistent behavior across account types, and includes URLs for upgrade, manage, and account recovery. No contradiction with annotations (readOnlyHint=true, openWorldHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
All sentences are informative and front-loaded with key purpose. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema, the description fully covers usage context, behavioral notes, and key response fields (URLs).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters needed; baseline is 4. Description adds context about returned URLs and account-specific behavior, exceeding baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it checks balances, plan, limits, and last 10 charges. Differentiates from LinkedIn-specific sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling first for budgeting before running data tools, and confirms it works on any account type. Also clarifies it's not for fetching platform data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one company's LinkedIn page: name, description, industry, employee count, headquarters, website, founding year, specialities, and the URN/numeric id you need for linkedin_search_people company filters. identifier accepts a company URL, the slug after /company/ (e.g. 'microsoft'), or a website domain like 'microsoft.com'; numeric ids and URNs are search-filter inputs, not fetch identifiers. Domains are resolved to a company and verified against that company's website: a domain identifier always QUOTES base+4 credits (set max_credits accordingly), and the 4-credit resolution surcharge is refunded at settlement when the domain was resolved before, so known domains settle at the base price. A domain that cannot be verified to a company returns INVALID_INPUT with the closest matches instead of a guessed company. Costs 4 credits base. Do not guess a slug from a brand name: slugs are vanity strings and a famous name can belong to an unrelated company's page (linkedin.com/company/anthropic is a small investment fund, not the AI lab). When you only know the company's name, pass its website domain instead -- the verified form -- and sanity-check the returned industry and description against what you expected. This tool does not search by name: if you only have an approximate company name, use linkedin_search_people's current_company filter with keywords (names are matched natively there) or give the exact slug. For the company's posts, use linkedin_get_posts with the same identifier (URL, slug, or website domain all work there too).
| Name | Required | Description | Default |
|---|---|---|---|
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| identifier | Yes | Company URL, slug (after /company/), or website domain (e.g. 'microsoft.com'). Numeric ids/URNs are not fetchable; use them only in linkedin_search_people company filters. | |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds critical behavioral details: domain resolution surcharge and refund, error handling for unverified domains, trial key limitations on freshness, and the non-fetchability of numeric IDs. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but somewhat lengthy with multiple paragraphs. While every sentence adds value, a more streamlined structure could improve readability. Still well-organized with clear warnings and usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema exists), the description thoroughly covers all aspects: input validation, error states, credit costs, alternatives, and expected return data. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds significant value: it explains valid identifier types (URL, slug, domain), warns against numeric IDs, clarifies freshness modes and trial restrictions, and describes max_credits behavior. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a company's LinkedIn page and lists the fields returned. It distinguishes from siblings by mentioning linkedin_get_posts for posts and linkedin_search_people for name-based searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives, including handling approximate names, slug guessing, and domain verification. It also explains credit costs and behaviors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the recent LinkedIn posts of one person or one company. identifier accepts a profile or company URL, a slug, a person URN, or a company website domain like 'microsoft.com'; the entity type is detected automatically. A domain resolves to its verified company first, exactly like linkedin_get_company: it QUOTES base+4 credits (set max_credits accordingly) and the surcharge is refunded at settlement for already-known domains, so they settle at the base price. Company URNs and numeric company ids are search-filter inputs, not fetch identifiers: use the company slug, URL, or domain here. Returns one page of posts (text, created_at, author, likes, comments_count, shares, is_repost, url) with a cursor for older posts. Costs 4 credits per page. Use this for 'what has X been posting', voice-of-company research, or activity checks before outreach. Not for reading one specific post you already have a URL for, and not for keyword search across LinkedIn; neither is supported in v1.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Cursor from a previous page for older posts. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| identifier | Yes | Person or company URL, slug, URN, or company website domain. | |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behaviors beyond annotations, including pricing (4 credits per page, surcharge for domains, refund), caching behavior (recent vs realtime), and identifier auto-detection. No contradiction with readOnlyHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, front-loaded with core purpose, then detailed parameters and usage. Every sentence serves a purpose, though slightly verbose due to pricing details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive, covering all aspects: purpose, identifier types, pricing, caching, pagination, and usage guidance. Output schema handles return values, making the description complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context beyond schema, such as how identifier resolves domains, surcharge refund logic, and max_credits function. This enhances understanding of parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches recent LinkedIn posts for one person or company, using specific verbs and resource. It distinguishes from siblings by explicitly stating it is not for reading a single post or keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (e.g., 'what has X been posting', voice-of-company research, activity checks) and when not to use (not for specific post or keyword search). It does not name alternative sibling tools but provides clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one person's LinkedIn profile. identifier accepts a profile URL, the slug after /in/ (e.g. 'williamhgates'), or a urn:li:fsd_profile URN; URLs are cleaned automatically. Always returns the overview (name, headline, location, current position, follower counts) plus up to 2 requested sections from about|experience|education|skills at no extra cost; each section beyond 2 adds 2 credits (max 4 sections). Costs 4 credits base. If you only have a name, use linkedin_search_people first; this tool does not search. Results from linkedin_search_people with is_anonymous=true cannot be fetched here; treat them as 'someone matching this exists' and stop. Companies belong to linkedin_get_company.
| Name | Required | Description | Default |
|---|---|---|---|
| sections | No | Extra profile sections. First 2 are included in the base price. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| identifier | Yes | Profile URL, slug (after /in/), or urn:li:fsd_profile URN. | |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost structure (4 credits base + 2 per extra section beyond 2), caching behavior (recent/realtime), trial key limitations, and credit refund policy. Annotations (readOnlyHint, openWorldHint) are supported and not contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is comprehensive yet efficient; each sentence adds information. Minor redundancy in listing sections again, but overall well-structured with front-loaded main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with full schema coverage, annotations, and output schema (implied), the description covers all necessary context: identifier types, cost, caching, limits, alternatives, and failure conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 4 parameters with descriptions (100% coverage). The description adds value by explaining sections cost, freshness credit implications, and max_credits as a rejection threshold, enriching beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch one person's LinkedIn profile' and specifies three accepted identifier formats (URL, slug, URN). It differentiates from siblings by directing name-based lookups to linkedin_search_people and company profiles to linkedin_get_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use alternative tools: 'If you only have a name, use linkedin_search_people first' and 'Companies belong to linkedin_get_company.' Also explains that anonymous search results cannot be fetched, and provides conditions for realtime vs cached fetches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify what a LinkedIn URL points at before fetching it. Give any LinkedIn profile, company, or post URL (utm params, www/m subdomains, trailing slashes are fine); get back {type: person|company|post, id, handle, canonical_url}. For profile URLs, id is the stable person URN; for company URLs, id is the stable company URN; for post URLs, id is the activity URN extracted from the URL. For people, use the returned handle or id with linkedin_get_profile or linkedin_get_posts. For companies, use the returned HANDLE with linkedin_get_company or linkedin_get_posts; the company URN/id is a linkedin_search_people filter input, not a fetch identifier. Costs 2 credits. Skip this tool when you already have a slug, URN, or clean URL: linkedin_get_profile and linkedin_get_company accept those directly, so resolving first would waste 2 credits. Not for non-LinkedIn URLs; it returns INVALID_INPUT for those.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A LinkedIn URL, e.g. https://www.linkedin.com/in/williamhgates or .../company/microsoft. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true, description adds credit cost, details of returned fields (id, handle, canonical_url), error for non-LinkedIn URLs, and specific URN extraction logic. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with front-loaded purpose, but the output format details make it slightly verbose. Still reasonably concise and organized, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description sufficiently explains return values, cost, error handling, and integration with sibling tools. No gaps for a resolve tool with clear annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for the url parameter. Description adds extra context: supports utm params, subdomains, trailing slashes, and gives examples, exceeding schema baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it identifies what a LinkedIn URL points at, with specific verb 'resolve' and resource 'LinkedIn URL'. It distinguishes from siblings like linkedin_get_profile and linkedin_get_company by explaining when to use this tool first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (before fetching a LinkedIn URL) and when not to use (when already have slug/URN/clean URL, as direct tools accept those). Names alternative tools and warns about credit cost, providing clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find people on LinkedIn by keywords and filters. The right tool when you have a name, role, or 'who is the X at Y' question without a profile URL. Pass keywords (free text: name, title, or both) and any of first_name, last_name, title, school, current_company, past_company. If keywords is omitted it is derived from the name or title filters; school or company filters alone are rejected with INVALID_INPUT, so include keywords with those. Company filters accept a company name, slug, numeric id, or URN. current_company names are matched by LinkedIn's own company search: typo-tolerant and fuzzy, so results can include people whose headline merely mentions the company; when you need exact filtering, pass the numeric id or URN (linkedin_get_company returns both). past_company names are resolved to an id for you. Costs 10 credits including the first 10 results; each further 10 results add 1 credit (limit max 30; trial keys max 10). A cursor page is a NEW call priced the same way by its own limit, so one limit=30 call is much cheaper than three limit=10 pages; prefer a larger limit over paginating. Do NOT combine a past_company NAME or a company-URL filter with limit=30: resolving those spends one of the call's three internal fetches, so that combination is rejected; keep limit<=20 with them or pass the numeric id. current_company names never spend a fetch, so they combine with any limit. Returns name, position, location, urn, public_identifier per result, a cursor for the next page, and total_matches. Results with is_anonymous=true are private profiles; do not pass them to linkedin_get_profile. For one known person with a URL/slug, call linkedin_get_profile directly instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results to return. | |
| title | No | Current job title filter. | |
| cursor | No | Cursor from a previous page. | |
| school | No | School or university name filter. | |
| keywords | No | Free-text query: a name, a title, or both. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| last_name | No | Last-name filter, exact match. | |
| first_name | No | First-name filter, exact match. | |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. | |
| past_company | No | Same accepted forms as current_company; names are resolved to an id server-side. | |
| current_company | No | Company name, slug, numeric id, or urn:li:fsd_company URN. Names are fuzzy-matched by LinkedIn; ids and URNs filter exactly. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses credit costs, caching behavior (freshness parameter), fuzzy matching on company names, the meaning of is_anonymous in results, and the rejection of certain parameter combinations. Annotations already indicate readOnlyHint and openWorldHint, but the description adds extensive behavioral context beyond these, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive and front-loaded with the main purpose, but it is lengthy due to detailed caveats and credit explanations. While every sentence adds value, it could be slightly more concise without losing essential information. Overall well-structured for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, output schema, annotations, sibling tools), the description covers all important aspects: return value structure, credit costs, pagination behavior, edge cases (is_anonymous, trial keys), and interaction with other tools. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds crucial meaning: explains that keywords can be derived from name/title filters, clarifies the accepted forms for company filters (name, slug, ID, URN), describes how current_company and past_company are resolved differently, and details the behavior of freshness. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: "Find people on LinkedIn by keywords and filters." It further specifies the use case: "The right tool when you have a name, role, or 'who is the X at Y' question without a profile URL." This distinguishes it from siblings like linkedin_get_profile, which is recommended for known persons with a URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: for one known person with a URL/slug, call linkedin_get_profile directly; warns against combining past_company NAME or company-URL filter with limit=30; explains when to use numeric IDs for exact filtering. It also details credit costs and pagination trade-offs, helping the agent make efficient choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full post content for up to 100 Reddit posts by their t3_ ids in one call -- the follow-up loop after reddit_search or reddit_get_subreddit_posts. Costs 4 credits for up to 10 ids, +1 credit per further 10 ids; every post comes back with its full body text. With exactly ONE id you may set detail to 'full' for +4 credits to also get the discussion tree (comments flattened in tree order with depth, about 200 per page, with a comments_cursor to continue), or pass comment_id (a t1_ id, also +4 credits) to fetch one specific comment in its post context. Post ids come from the other Reddit tools or from reddit_resolve_url on a post URL. Not for discovering posts; search first, then batch-fetch here.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Discussion-tree order; only with detail 'full'. | |
| cursor | No | comments_cursor from a previous detail='full' page. | |
| detail | No | 'full' adds the discussion tree; only valid with exactly one id, +4 credits. | concise |
| post_ids | Yes | 1 to 100 post ids with the t3_ prefix, e.g. ["t3_1tbups6"]. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| comment_id | No | A t1_ comment id to fetch in context; only valid with exactly one post id, +4 credits like detail 'full'. | |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description elaborates on credit costs, pagination, caching behavior, freshness options with trial key limitations, and conditions for using detail and comment_id. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and covers many nuances, but every sentence adds value. It is front-loaded with the main purpose and then provides necessary details. Slightly long but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, output schema exists), the description covers all states: multiple ids, single id with/without detail, comments cursor pagination, caching, and credit costs. It is complete for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning beyond schema: validity conditions for parameters (detail 'full' only with one id, sort only with detail 'full'), credit implications, caching behavior, and explanation of cursor usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches full post content for up to 100 Reddit posts by t3_ ids, and optionally retrieves a discussion thread. It distinguishes from siblings by explicitly noting it is the follow-up after reddit_search or reddit_get_subreddit_posts and not for discovering posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (after search tools, batch fetch) and when not to use (not for discovering posts). Mentions alternatives like reddit_resolve_url for post ids, and details credit costs and conditions for different modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one subreddit's profile: title, description, subscriber and active-user counts, age, NSFW flag, and topics. subreddit_name is the name without the r/ prefix, e.g. 'selfhosted'; a full reddit.com URL also works. Set include_settings to also get the community rules and moderator list for +2 credits (useful before posting or judging moderation culture). Costs 4 credits base. Subscriber counts here are the standard sizing signal for market research. This tool does not return posts: read the feed with reddit_get_subreddit_posts, and discover subreddits you don't know by name with reddit_search type=subreddits.
| Name | Required | Description | Default |
|---|---|---|---|
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. | |
| subreddit_name | Yes | Subreddit name without the r/ prefix, e.g. 'selfhosted'. Full URLs are accepted and cleaned. | |
| include_settings | No | Also return rules and moderators for +2 credits. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost (4 credits base, +2 for settings), freshness/caching behavior (recent vs realtime, trial limitations), and confirms read-only nature. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with primary purpose, then parameter details, then sibling contrasts. Every sentence is informative; no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, annotations are present, and schema coverage is 100%, the description covers all necessary aspects: what is returned, when to use, parameter semantics, limitations, and alternatives. Completely sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context beyond schema: subreddit_name accepts r/ prefix or full URLs; include_settings adds rules/moderator list for +2 credits; freshness explains caching and trial fallback; max_credits is a spend ceiling, not a reservation. All 4 parameters are given meaningful elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a subreddit's profile with specific data fields (title, description, counts, etc.). It explicitly distinguishes from sibling tools reddit_get_subreddit_posts (for posts) and reddit_search (for discovery).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use for subreddit details and market research; use reddit_get_subreddit_posts for posts; use reddit_search for discovery. Also advises using include_settings before posting or judging moderation culture. Mentions caching and trial key limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one page of posts from a single subreddit, the community-monitoring primitive. subreddit_name is the name without the r/ prefix. sort defaults to the subreddit's own front-page order (best); use sort=new for monitoring. sort=top and controversial need a range, but the window is currently not applied upstream on this feed: top returns the subreddit's all-time top posts whatever range says (time-windowed tops are a known gap here; reddit_search's range DOES work for keyword queries). Costs 4 credits per page; a cursor page is a NEW call priced the same way. Reddit splices about one promoted ad into every feed page; these are dropped by default, so set include_promoted=true only when ads ARE the data you want (ad intelligence, who targets this community) -- kept ads carry is_promoted=true. Returns post summaries (title, author, upvotes, comment_count, created_at, permalink, id) with a cursor for older posts; bodies and discussions come from reddit_get_post with the returned ids. For keyword search across all of Reddit use reddit_search; this tool takes no query.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Defaults to the subreddit's front-page order. | |
| range | No | Required with sort=top or controversial, but currently not applied upstream on this feed (results are all-time). | |
| cursor | No | Cursor from a previous page for older posts. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. | |
| subreddit_name | Yes | Subreddit name without the r/ prefix, e.g. 'selfhosted'. | |
| include_promoted | No | Keep the promoted ads Reddit splices into the feed (marked is_promoted). Default drops them. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/openWorldHint annotations by disclosing credit costs, the fact that cursor pages are new calls, the ad-splicing behavior and default dropping of promoted posts, the range-window bug, and the return shape. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place, front-loading the core purpose and then layering caveats and alternatives in a logical order. The caveats about range, credits, and ads are necessary rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and output schema, the description is thorough: it names the returned fields, explains the cursor for pagination, points to the companion tool for bodies/discussions, and covers the main edge cases. Nothing required to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds real semantic value: it explains sort=new for monitoring, warns that range is not currently applied upstream for top/controversial, and clarifies include_promoted's purpose. This is above the baseline, though not all parameters receive equal narrative treatment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Fetch one page of posts from a single subreddit.' It also distinguishes itself from sibling tools by stating this tool takes no query, that bodies/discussions come from reddit_get_post, and that keyword search should use reddit_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: use sort=new for monitoring, use reddit_search for keyword queries, and use reddit_get_post for post bodies. It also warns about the range caveat with sort=top and when to set include_promoted=true, making selection and invocation conditions clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one Reddit user's public profile: username, account age, karma, follower count, and description. username is the name without the u/ prefix, e.g. 'spez'; a full profile URL also works. Add up to 2 sections from comments|posts|subreddits at 2 credits each: comments and posts return that user's recent activity (first page), subreddits returns where they are active. Costs 4 credits base. Use this to profile loud voices found via reddit_search before quoting or engaging them. To find users by topic, use reddit_search type=users; this tool needs an exact username.
| Name | Required | Description | Default |
|---|---|---|---|
| sections | No | Extra activity sections, 2 credits each (max 2 per call). | |
| username | Yes | Reddit username without the u/ prefix, e.g. 'spez'. Full profile URLs are accepted and cleaned. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral details beyond annotations: base cost (4 credits), extra sections cost (2 credits each), freshness options (cached vs realtime), trial key limitations, and that activity sections return 'first page'. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise yet complete, front-loaded with main purpose, then details. Each sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 100% schema coverage, annotations, and an output schema, the description covers usage, cost, parameters, and alternatives comprehensively. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value: explains username format (without u/ prefix, full URL works), sections limit (max 2), freshness details (credits and fallback behavior), and clarifies that max_credits is a spending ceiling. All parameters are well-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Fetch one Reddit user's public profile' and lists specific data fields (username, account age, karma, etc.). It distinguishes from sibling tools like reddit_search and reddit_get_post, ensuring clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this to profile loud voices found via reddit_search before quoting or engaging them.' Also provides when-not guidance: 'To find users by topic, use reddit_search type=users; this tool needs an exact username.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify what a Reddit URL points at before fetching it. Give any reddit.com or redd.it URL (share links, old.reddit.com, trailing params are fine); get back {type: subreddit|user|post|comment, id, handle, canonical_url}. Post URLs yield the t3_ id for reddit_get_post; comment permalinks yield the t1_ id; subreddit and user URLs yield the name for reddit_get_subreddit or reddit_get_user. Costs 2 credits and parses offline without fetching the page. Skip this tool when you already have a t3_/t1_ id, subreddit name, or username: the other Reddit tools accept those directly. Not for non-Reddit URLs; it returns INVALID_INPUT for those.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A Reddit URL, e.g. https://www.reddit.com/r/selfhosted/comments/1tbups6/... or https://redd.it/1tbups6. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, indicating no side effects. The description adds valuable context: 'Costs 2 credits and parses offline without fetching the page' and returns INVALID_INPUT for non-Reddit URLs. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise and well-structured, with clear sentences. It could be slightly shorter, but every sentence adds useful information. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown but flagged as true), so the description doesn't need to detail return values. However, it explains the output mapping and behavior adequately. With good annotations and a single parameter, the description is complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter. The description enhances the schema by providing examples of valid URLs and explaining how the output maps to other tools (e.g., t3_ id for reddit_get_post). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Identify what a Reddit URL points at before fetching it.' It specifies the output fields (type, id, handle, canonical_url) and distinguishes from sibling tools like reddit_get_subreddit by focusing on URL resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 'Give any reddit.com or redd.it URL.' Explicit when-not-to-use: 'Skip this tool when you already have a t3_/t1_ id, subreddit name, or username.' Also states it's not for non-Reddit URLs, providing clear boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all of Reddit by keywords. type picks the target: posts (default), comments (what people actually say about a product, problem, or brand -- unique to Reddit search), subreddits (find communities), users. Pass query as free text up to 256 characters; decompose broad topics into several narrower queries, since result depth per query is capped upstream around a few hundred results. sort applies to posts (relevance|top|new|hot|comment_count) and comments (relevance|top|new); range (past_hour..all_time) applies to posts only; both are rejected with INVALID_INPUT elsewhere. Costs 6 credits per page; a cursor page is a NEW call priced the same way. Returns one page of summaries (author, title or comment text, upvotes, comment_count, created_at, permalink, id) with a cursor; there is no server-side time window on comment search, so for monitoring filter on created_at yourself and poll with sort=new. Fetch full post bodies and discussion threads with reddit_get_post; read one community's feed with reddit_get_subreddit_posts. For high-volume recency sweeps across X instead, use x_search.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | posts: any value; comments: relevance|top|new; invalid for subreddits and users. | |
| type | No | What to search. 'comments' finds mentions inside discussions; 'subreddits' finds communities. | posts |
| query | Yes | Free-text keywords, e.g. 'self hosted photo backup'. Not a URL; use reddit_resolve_url for URLs. | |
| range | No | Time window. posts only. | |
| cursor | No | Cursor from a previous page. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey the tool is read-only and open-world, but the description adds a large amount of behavioral transparency beyond that: credit costs per page and per cursor call, freshness cache behavior with fallback refunds, trial-key limitations on realtime, upstream per-query result-depth capping (a few hundred), and the absence of a server-side time window on comment search. This is exactly what an agent needs to predict behavior beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense. Every clause earns its place: the result cap, credit costs, sort/range constraints, freshness behavior, cursor pagination, and sibling routing are all necessary for correct call construction. It avoids redundant phrasing and leads with the core purpose before diving into per-type and pricing nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool (7 params, 4 enums, cost model, pagination, cache modes, type-specific behavior) with an output schema, yet the description covers all the non-obvious interactions, including trial-key limitations and polling guidance for comment search. The only missing details (full output fields) are already covered by the output schema, so nothing an agent needs is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds meaningful semantics: it explains the semantic purpose of `type=comments` ('what people actually say about a product...'), the allowed sort values per type, that range applies only to posts, and that cursor pages are new calls costing credits profit. It also warns that sort/range misuse is rejected with INVALID_INPUT. This goes far beyond the baseline schema-only value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource ('Search all of Reddit by keywords') and immediately distinguishes target types (`type` picks posts, comments, subreddits, users). It also names sibling tools for adjacent tasks (reddit_get_post, reddit_get_subreddit_posts, x_search), so an agent can unambiguously tell this from cousins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to prefer this tool and when not to: use `reddit_get_post` for full post bodies/threads, `reddit_get_subreddit_posts` for a community's feed, and `x_search` for high-volume recency sweeps on X. It also clarifies the unique value of comment search, making alternative-selection logic executable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one X account's profile: name, bio, location, website, follower/following counts, tweet and media counts, verification state, and join date. identifier accepts a screen name without the @ (e.g. 'nasa'), a full x.com or twitter.com profile URL, or the numeric account id; numeric strings are treated as ids, and the rare all-digit handle can be forced with by='screen_name'. Costs 4 credits. The returned platform_fields.id is stable across handle changes; store it for repeat lookups. To find accounts by topic use x_search type=people, and to read what an account posts use x_get_tweets; this tool returns no tweets.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | Force how identifier is interpreted; auto-detected when omitted. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| identifier | Yes | Screen name without the @ (e.g. 'nasa'), profile URL, or numeric account id. | |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond readOnlyHint and openWorldHint annotations by detailing credit costs, caching behavior (recent vs realtime), trial key limitations, refund policy, and the stability of the returned id. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph is dense and front-loaded with purpose. Every sentence adds value, but could be slightly more structured (e.g., bullet points) for easier scanning given the amount of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, identifier handling, parameter details, costs, caching, authentication implications, sibling tool distinctions, and output stability. With output schema present, no need to detail return values further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value: explains acceptable identifier formats (screen name, URL, numeric ID), how the 'by' parameter forces interpretation, freshness credit/caching details, and max_credits spend ceiling logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch one X account's profile' and lists specific fields returned. It distinguishes from siblings: x_search (type=people) for finding accounts by topic and x_get_tweets for reading posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (fetch profile) and when not to (use x_search or x_get_tweets). Also explains identifier formats and interpretation, including edge cases like all-digit handles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one tweet by id with full engagement metrics: views, likes, retweets, quotes, replies, bookmarks, language, and the quoted tweet inline when there is one. tweet_id is the numeric id from a tweet URL (the digits after /status/) or from any other X tool's results; full tweet URLs are accepted too. Costs 4 credits. Use this to verify engagement before citing a tweet or to read a quoted thread hop by hop. It returns a single tweet, not the conversation around it: for the author's other tweets use x_get_tweets, and to find tweets by topic use x_search.
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_id | Yes | Numeric tweet id, e.g. '2054497961162478079', or a full tweet URL. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it mentions the tool costs 4 credits, explains the freshness parameter's credit impact, and notes trial keys reject realtime. This aligns with readOnlyHint=true (read operation) and openWorldHint=true (no side effects). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 90 words, front-loaded with key purpose and engagement metrics, then quickly covers cost, parameter usage, and when to use alternatives. Every sentence adds essential information, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-tweet fetch tool, the description covers purpose, input (tweet_id format and URL acceptance), credit cost, parameter options, and explicit guidance on when to use this vs. siblings. With an output schema present, return values are not needed. The tool's complexity is low and description fully addresses it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value: explains tweet_id accepts full URL, freshness differences and credit cost, and max_credits as spending ceiling. It goes beyond schema to include credit costs, trial key behavior, and practical usage tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch one tweet by id with full engagement metrics', specifying the verb, resource, and scope. It distinguishes from siblings by noting it returns a single tweet, not conversation, and points to x_get_tweets and x_search for alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to verify engagement before citing a tweet or to read a quoted thread hop by hop' and provides when-not-to-use by stating 'not the conversation' and naming alternatives: use x_get_tweets for author's tweets and x_search for topic search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one page of an X account's timeline. identifier is a screen name, profile URL, or numeric id (auto-detected). mode picks the view: posts (default) is the account's own tweets, posts_and_replies includes their replies, highlights is the account's pinned highlights tab. include_retweets (default true) filters retweets out when false. Costs 4 credits per page; a cursor page is a NEW call priced the same way. Returns tweet summaries with engagement counts and a cursor for older tweets. Use this for 'what has X been posting', voice checks before outreach, or drafting replies in an account's register. For keyword search across all of X use x_search; for one specific tweet you already have, x_get_tweet.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Which timeline view to read. | posts |
| cursor | No | Cursor from a previous page for older tweets. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| identifier | Yes | Screen name without the @, profile URL, or numeric account id. | |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. | |
| include_retweets | No | Set false to drop retweets from the page. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld hints. The description adds value beyond annotations: cost details (4 credits per page, fresh cursor costs anew), pagination (cursor for older tweets), caching/real-time freshness behavior, and trial key limitations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but presented as a dense paragraph. While not overly verbose, it could benefit from structuring (e.g., bullet points for modes) to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, enums, output schema), the description covers all essentials: functionality, parameter details, costs, pagination, return structure (summaries with engagements and cursor), and alternatives. Output schema exists so return value details are unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context: identifier auto-detection, mode explanations, freshness modes with credit differences, max_credits as spend ceiling. This enriches the bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a page of an X account's timeline. It distinguishes from siblings by explicitly mentioning alternatives like x_search for keyword search and x_get_tweet for a specific tweet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios ('what has X been posting', voice checks, drafting replies) and directs to alternatives for other needs (x_search, x_get_tweet).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify what an X (formerly Twitter) URL points at before fetching it. Give any x.com or twitter.com URL (mobile links, query params, /i/web/status forms are fine); get back {type: profile|tweet, id, handle, canonical_url}. Tweet URLs yield the numeric id for x_get_tweet; profile URLs yield the handle for x_get_profile or x_get_tweets. Costs 2 credits and parses offline without fetching the page. t.co short links cannot be expanded offline and return INVALID_INPUT telling you so; expand them in your own browser step first. Skip this tool when you already have a handle or tweet id: the other X tools accept those directly.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | An X URL, e.g. https://x.com/nasa/status/2054497961162478079 or https://twitter.com/nasa. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: costs 2 credits, parses offline without fetching the page, and t.co links return INVALID_INPUT. No contradiction with readOnlyHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (3 sentences) and well-structured, with the most critical information front-loaded. Every sentence adds unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, usage, limitations (t.co), cost, and referral to sibling tools. Output schema exists so description needn't detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description elaborates on acceptable URL formats (mobile, query params, /i/web/status), adding value beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves X URLs to determine if they point to a profile or tweet, returning type, id, handle, and canonical URL. It distinguishes from sibling tools like x_get_tweet and x_get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (before fetching a URL) and when not to (skip if handle or tweet ID already known). Provides alternative tools (x_get_tweet, x_get_profile, x_get_tweets) and warns about t.co short links requiring expansion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search X by keywords. type picks the mode: recent (default) is the deep chronological sweep and keeps paginating as far as you follow the cursor; popular returns the highest-engagement tweets for the query; people finds accounts and returns a single page (no cursor). Advanced query operators pass through verbatim, e.g. "from:nasa", "min_faves:100", exact phrases in quotes -- there is no separate date parameter, so use since:/until: operators for time windows. Costs 6 credits per page; a cursor page is a NEW call priced the same way, so a deep sweep costs linearly in pages. Returns tweet summaries (text, author with follower count, views, likes, retweets, replies, created_at, url, id) with a cursor. Fetch one tweet's full detail with x_get_tweet and an account's timeline with x_get_tweets. For comment-level sentiment inside topic communities, reddit_search type=comments is usually the sharper instrument.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | recent = chronological deep sweep; popular = top engagement; people = account search (single page). | recent |
| query | Yes | Free-text keywords; X advanced operators work, e.g. 'claude code from:AnthropicAI since:2026-06-01'. | |
| cursor | No | Cursor from a previous page. Not valid with type 'people'. | |
| freshness | No | recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data). Trial keys are cached-only and reject realtime with TRIAL_CAP_EXCEEDED; paying upgrades this same key to unlock it. | recent |
| max_credits | No | Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| common | Yes | |
| entity | Yes | |
| platform | Yes | |
| freshness | Yes | |
| data_as_of | Yes | |
| canonical_url | Yes | |
| schema_version | Yes | |
| platform_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost per page (6 credits), pagination behavior (cursor page is a new call), freshness parameter implications (cached vs realtime, trial key limitations), lack of date parameter, and return structure (tweet summaries with cursor). No contradiction with readOnlyHint/openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with all necessary information, front-loaded with core purpose. Somewhat dense but well-organized; could be slightly restructured for even easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, usage, cost, parameters, return format, sibling differentiation, and limitations. Output schema exists but description still summarizes return fields adequately. No gaps for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds major value: explains behavioral differences of type enum, cursor incompatibility with 'people', freshness cost dynamics, and advanced operator usage with examples. Greatly enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Search X by keywords' and elaborates on three distinct modes (recent, popular, people) with specific behaviors. It distinguishes from sibling tools like x_get_tweet and x_get_tweets, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use each mode: recent for deep chronological sweep, popular for top engagement, people for account search. Provides alternatives: fetch single tweet with x_get_tweet, timeline with x_get_tweets, and mentions reddit_search for comment-level sentiment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
reddit_get_postreddit_get_subredditreddit_get_subreddit_postsreddit_get_userreddit_resolve_urlreddit_searchx_get_profilex_get_tweetx_get_tweetsx_resolve_urlx_searchget_companyget_postsget_profileget_usage8 fields changedOutput schema / properties / common / properties / free_tierAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_per_ip_day": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "remaining_today": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "resets": {
+ "description": "UTC midnight when the day budget resets. ISO 8601.",
+ "type": "string"
+ },
+ "used_today": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "credits_per_ip_day",
+ "used_today",
+ "remaining_today",
+ "resets"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Present on trial keys: the shared per-IP day budget this key actually spends (balance_remaining stays 0 on the free tier; other callers on the same IP draw from the same pool). Null on paid plans."
+}Output schema / properties / common / requiredPrevious value: -[
- "plan",
- "platforms",
- "balance_remaining",
- "realtime_ops_used",
- "realtime_ops_limit",
- "concurrent_limit",
- "recent_receipts",
- "claim_url",
- "upgrade_url",
- "manage_url"
-]New value: +[
+ "plan",
+ "platforms",
+ "balance_remaining",
+ "free_tier",
+ "realtime_ops_used",
+ "realtime_ops_limit",
+ "concurrent_limit",
+ "recent_receipts",
+ "claim_url",
+ "upgrade_url",
+ "manage_url"
+]Output schema / properties / freshness / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "cache_age_seconds": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "freshness_requested": {
- "enum": [
- "recent",
- "realtime"
- ],
- "type": "string"
- },
- "freshness_served": {
- "enum": [
- "recent",
- "realtime",
- "stale"
- ],
- "type": "string"
- },
- "served_at": {
- "type": "string"
- },
- "source_retrieved_at": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "When the data was fetched from the source. ISO 8601."
- }
- },
- "required": [
- "source_retrieved_at",
- "served_at",
- "cache_age_seconds",
- "freshness_requested",
- "freshness_served"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "cache_age_seconds": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "freshness_requested": {
+ "enum": [
+ "recent",
+ "realtime"
+ ],
+ "type": "string"
+ },
+ "freshness_served": {
+ "enum": [
+ "recent",
+ "realtime",
+ "stale"
+ ],
+ "type": "string"
+ },
+ "served_at": {
+ "type": "string"
+ },
+ "served_from_cache": {
+ "description": "True when these bytes were served from cache rather than fetched for this call. source_retrieved_at says how old they are.",
+ "type": "boolean"
+ },
+ "source_retrieved_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "When the data was fetched from the source. ISO 8601."
+ }
+ },
+ "required": [
+ "source_retrieved_at",
+ "served_at",
+ "cache_age_seconds",
+ "served_from_cache",
+ "freshness_requested",
+ "freshness_served"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / platform / anyOfAdded value: +[
+ {
+ "enum": [
+ "linkedin",
+ "reddit",
+ "x"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / platform / constRemoved value: -"linkedin"Output schema / properties / platform / typeRemoved value: -"string"Output schema / properties / usage / properties / free_tier_hintAdded value: +{
+ "description": "Present on free-tier trial-key calls: what budget the call drew from and that paying upgrades this same key. Near the daily cap on unclaimed keys it also carries a claim link to relay to your human (claiming adds one-time credits).",
+ "type": "string"
+}Output schema / properties / usage / properties / keyless_hintRemoved value: -{
- "description": "Present on keyless calls: what budget the call drew from and how to get a key with its own balance.",
- "type": "string"
-}linkedin_get_companylinkedin_get_postslinkedin_get_profilelinkedin_resolve_urllinkedin_search_peopleresolve_urlsearch_peopleget_company3 fields changedOutput schema / properties / schema_version / constPrevious value: -"1"New value: +"2"Output schema / properties / usage / properties / keyless_hintAdded value: +{
+ "description": "Present on keyless calls: what budget the call drew from and how to get a key with its own balance.",
+ "type": "string"
+}Output schema / properties / usage / properties / provision_hintRemoved value: -{
- "description": "Present on keyless calls: how to get a free trial key with its own budget.",
- "type": "string"
-}get_posts3 fields changedOutput schema / properties / schema_version / constPrevious value: -"1"New value: +"2"Output schema / properties / usage / properties / keyless_hintAdded value: +{
+ "description": "Present on keyless calls: what budget the call drew from and how to get a key with its own balance.",
+ "type": "string"
+}Output schema / properties / usage / properties / provision_hintRemoved value: -{
- "description": "Present on keyless calls: how to get a free trial key with its own budget.",
- "type": "string"
-}get_profile3 fields changedOutput schema / properties / schema_version / constPrevious value: -"1"New value: +"2"Output schema / properties / usage / properties / keyless_hintAdded value: +{
+ "description": "Present on keyless calls: what budget the call drew from and how to get a key with its own balance.",
+ "type": "string"
+}Output schema / properties / usage / properties / provision_hintRemoved value: -{
- "description": "Present on keyless calls: how to get a free trial key with its own budget.",
- "type": "string"
-}get_usage5 fields changedOutput schema / properties / common / properties / platformsAdded value: +{
+ "description": "Platforms this account's key may call. Grants are explicit; write to hello@veezee.io to enable more.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / common / requiredPrevious value: -[
- "plan",
- "balance_remaining",
- "realtime_ops_used",
- "realtime_ops_limit",
- "concurrent_limit",
- "recent_receipts",
- "claim_url",
- "upgrade_url",
- "manage_url"
-]New value: +[
+ "plan",
+ "platforms",
+ "balance_remaining",
+ "realtime_ops_used",
+ "realtime_ops_limit",
+ "concurrent_limit",
+ "recent_receipts",
+ "claim_url",
+ "upgrade_url",
+ "manage_url"
+]Output schema / properties / schema_version / constPrevious value: -"1"New value: +"2"Output schema / properties / usage / properties / keyless_hintAdded value: +{
+ "description": "Present on keyless calls: what budget the call drew from and how to get a key with its own balance.",
+ "type": "string"
+}Output schema / properties / usage / properties / provision_hintRemoved value: -{
- "description": "Present on keyless calls: how to get a free trial key with its own budget.",
- "type": "string"
-}provisionresolve_url3 fields changedOutput schema / properties / schema_version / constPrevious value: -"1"New value: +"2"Output schema / properties / usage / properties / keyless_hintAdded value: +{
+ "description": "Present on keyless calls: what budget the call drew from and how to get a key with its own balance.",
+ "type": "string"
+}Output schema / properties / usage / properties / provision_hintRemoved value: -{
- "description": "Present on keyless calls: how to get a free trial key with its own budget.",
- "type": "string"
-}search_people3 fields changedOutput schema / properties / schema_version / constPrevious value: -"1"New value: +"2"Output schema / properties / usage / properties / keyless_hintAdded value: +{
+ "description": "Present on keyless calls: what budget the call drew from and how to get a key with its own balance.",
+ "type": "string"
+}Output schema / properties / usage / properties / provision_hintRemoved value: -{
- "description": "Present on keyless calls: how to get a free trial key with its own budget.",
- "type": "string"
-}get_company8 fields changedInput schema / properties / freshness / defaultRemoved value: -"recent"Input schema / properties / freshness / descriptionRemoved value: -"recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data)."Input schema / properties / freshness / enumRemoved value: -[
- "recent",
- "realtime"
-]Input schema / properties / max_credits / descriptionRemoved value: -"Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling."Input schema / properties / max_credits / maximumRemoved value: -9007199254740991Input schema / properties / max_credits / minimumRemoved value: -0Input schema / properties / max_credits / typePrevious value: -"integer"New value: +"number"Output schema / properties / usage / properties / provision_hintAdded value: +{
+ "description": "Present on keyless calls: how to get a free trial key with its own budget.",
+ "type": "string"
+}get_posts9 fields changedInput schema / properties / cursor / descriptionRemoved value: -"Cursor from a previous page for older posts."Input schema / properties / freshness / defaultRemoved value: -"recent"Input schema / properties / freshness / descriptionRemoved value: -"recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data)."Input schema / properties / freshness / enumRemoved value: -[
- "recent",
- "realtime"
-]Input schema / properties / max_credits / descriptionRemoved value: -"Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling."Input schema / properties / max_credits / maximumRemoved value: -9007199254740991Input schema / properties / max_credits / minimumRemoved value: -0Input schema / properties / max_credits / typePrevious value: -"integer"New value: +"number"Output schema / properties / usage / properties / provision_hintAdded value: +{
+ "description": "Present on keyless calls: how to get a free trial key with its own budget.",
+ "type": "string"
+}get_profile11 fields changedInput schema / properties / freshness / defaultRemoved value: -"recent"Input schema / properties / freshness / descriptionRemoved value: -"recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data)."Input schema / properties / freshness / enumRemoved value: -[
- "recent",
- "realtime"
-]Input schema / properties / max_credits / descriptionRemoved value: -"Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling."Input schema / properties / max_credits / maximumRemoved value: -9007199254740991Input schema / properties / max_credits / minimumRemoved value: -0Input schema / properties / max_credits / typePrevious value: -"integer"New value: +"number"Input schema / properties / sections / descriptionRemoved value: -"Extra profile sections. First 2 are included in the base price."Input schema / properties / sections / items / enumRemoved value: -[
- "about",
- "experience",
- "education",
- "skills"
-]Input schema / properties / sections / maxItemsRemoved value: -4Output schema / properties / usage / properties / provision_hintAdded value: +{
+ "description": "Present on keyless calls: how to get a free trial key with its own budget.",
+ "type": "string"
+}get_usage1 field changedOutput schema / properties / usage / properties / provision_hintAdded value: +{
+ "description": "Present on keyless calls: how to get a free trial key with its own budget.",
+ "type": "string"
+}provision1 field changedOutput schema / properties / usage / properties / provision_hintAdded value: +{
+ "description": "Present on keyless calls: how to get a free trial key with its own budget.",
+ "type": "string"
+}resolve_url1 field changedOutput schema / properties / usage / properties / provision_hintAdded value: +{
+ "description": "Present on keyless calls: how to get a free trial key with its own budget.",
+ "type": "string"
+}search_people21 fields changedInput schema / properties / current_company / descriptionRemoved value: -"Company name, slug, numeric id, or urn:li:fsd_company URN."Input schema / properties / cursor / descriptionRemoved value: -"Cursor from a previous page."Input schema / properties / first_name / descriptionRemoved value: -"First-name filter, exact match."Input schema / properties / freshness / defaultRemoved value: -"recent"Input schema / properties / freshness / descriptionRemoved value: -"recent (default) serves cached data from the last few hours when available; realtime forces a live fetch for +2 credits (refunded if we fall back to cached data)."Input schema / properties / freshness / enumRemoved value: -[
- "recent",
- "realtime"
-]Input schema / properties / keywords / descriptionRemoved value: -"Free-text query: a name, a title, or both."Input schema / properties / last_name / descriptionRemoved value: -"Last-name filter, exact match."Input schema / properties / limit / defaultRemoved value: -10Input schema / properties / limit / descriptionRemoved value: -"How many results to return."Input schema / properties / limit / maximumRemoved value: -30Input schema / properties / limit / minimumRemoved value: -1Input schema / properties / limit / typePrevious value: -"integer"New value: +"number"Input schema / properties / max_credits / descriptionRemoved value: -"Spend ceiling for this one call. The call is rejected (nothing charged) if its quote exceeds this. Only the quote is ever reserved, never this ceiling."Input schema / properties / max_credits / maximumRemoved value: -9007199254740991Input schema / properties / max_credits / minimumRemoved value: -0Input schema / properties / max_credits / typePrevious value: -"integer"New value: +"number"Input schema / properties / past_company / descriptionRemoved value: -"Same accepted forms as current_company."Input schema / properties / school / descriptionRemoved value: -"School or university name filter."Input schema / properties / title / descriptionRemoved value: -"Current job title filter."Output schema / properties / usage / properties / provision_hintAdded value: +{
+ "description": "Present on keyless calls: how to get a free trial key with its own budget.",
+ "type": "string"
+}get_companyget_postsget_profileget_usageprovisionresolve_urlsearch_people
Add one secure layer between your agents and this server.