Which integrations are available for this server?

Provides tools for Reddit data access, including searching posts/comments/users/subreddits, retrieving subreddit details and posts, getting user profiles, and resolving URLs.

Veezee

by veezeehq

Overview Schema Source Related Servers Discussions Admin

JavaScript

Veezee MCP server

LinkedIn, Reddit, and X (formerly Twitter) data for AI agents, over MCP or REST. This repo is the public home and issue tracker for the hosted servers on the official MCP Registry: io.veezee/linkedin (3.1.0), io.veezee/reddit (1.1.0), and io.veezee/x-twitter (1.1.0). The server is a hosted service; this repo also ships a small stdio proxy (npx github:veezeehq/veezee-mcp) for clients that spawn a local command.

Every call needs a free key, and minting one costs nothing: no signup, no card, no human. See Quickstart below. The free tier is 200 credits per IP per day across all platforms, cached data, first page only. Paying at https://veezee.io/upgrade credits the same key with a higher budget, realtime freshness, and full pagination.
Website and docs: https://veezee.io
Found a bug or a gap? Open an issue or write hello@veezee.io.

Run locally (stdio)

For MCP clients that spawn a local command instead of connecting to a URL:

npx github:veezeehq/veezee-mcp

The proxy connects to https://mcp.veezee.io/all and mints a free trial key on first run (no signup). Set VEEZEE_API_KEY to reuse one key across runs, and VEEZEE_MCP_URL to point at a single-platform mount. Docker: docker build -t veezee-mcp . && docker run -i veezee-mcp.

Related MCP server: Xpoz MCP Server

Mounts

Four endpoints, all streamable-http, same auth and pricing:

mount	covers
`https://mcp.veezee.io/linkedin`	LinkedIn only (5 tools + `get_usage`)
`https://mcp.veezee.io/reddit`	Reddit only (6 tools + `get_usage`)
`https://mcp.veezee.io/x`	X (formerly Twitter) only (5 tools + `get_usage`)
`https://mcp.veezee.io/all`	Every platform (17 tools + `get_usage`)

Pick a single-platform mount when your agent only needs one platform: a smaller tool list is easier for the model to pick from correctly and costs less context per turn. Pick /all when one task spans platforms, e.g. a research brief that pulls LinkedIn, Reddit, and X signal on the same account, or a monitoring loop that watches more than one platform at once.

The 17 tools

LinkedIn (https://mcp.veezee.io/linkedin)

tool	what it does	credits
`linkedin_resolve_url`	identify a LinkedIn URL	2
`linkedin_get_profile`	get a person profile	4 base (2 sections included, +2/section, max 4)
`linkedin_search_people`	search people	10 base (10 results included, +1/10 more, max 30)
`linkedin_get_company`	get a company	4 base (+4 to resolve a new domain)
`linkedin_get_posts`	recent posts by a person or company	4/page (+4 to resolve a new domain)

Reddit (https://mcp.veezee.io/reddit)

tool	what it does	credits
`reddit_search`	search posts, comments, subreddits, or users	6/page
`reddit_get_subreddit`	get subreddit details	4 base (+2 for rules and moderators)
`reddit_get_subreddit_posts`	get a subreddit's posts	4/page
`reddit_get_user`	get a Reddit user	4 base (+2/section, max 2)
`reddit_get_post`	get posts by id, with an optional discussion thread	4 for up to 10 ids (+1/10 more, max 100; +4 for the full thread or one comment in context)
`reddit_resolve_url`	identify a Reddit URL	2

X, formerly Twitter (https://mcp.veezee.io/x)

tool	what it does	credits
`x_search`	search X (formerly Twitter)	6/page
`x_get_profile`	get an X profile	4
`x_get_tweets`	get an account's tweets	4/page
`x_get_tweet`	get one tweet with full metrics	4
`x_resolve_url`	identify an X URL	2

Every mount

tool	what it does	credits
`get_usage`	check credits and recent charges	0

Any tool call can set freshness: "realtime" for +2 credits to force a live fetch instead of cached data. Full tool reference with schemas: https://veezee.io/docs

Quickstart

Every tool call needs a key, and getting one costs nothing. Mint one directly:

curl -s -X POST https://api.veezee.io/v1/keys/mint

That returns a vz_trial_... key with the same free-tier budget as before: 200 credits per IP per day, cached data, first page only. Drop it into your MCP client config as a bearer header, then reconnect. Example for /all (swap in /linkedin, /reddit, or /x for a single-platform mount):

{
  "mcpServers": {
    "veezee": {
      "url": "https://mcp.veezee.io/all",
      "headers": { "Authorization": "Bearer vz_trial_..." }
    }
  }
}

Don't want to mint a key by hand first? If your client supports MCP authorization (Claude Code, claude.ai connectors), just connect: the server answers unauthenticated requests with a sign-in challenge and the client opens a Veezee sign-in in your browser (email code, no password, no card). Clients without that support get a KEY_REQUIRED error whose message spells out the mint step (POST /v1/keys/mint) plus a mint_url. Either route, you get from zero to a working connection with no signup form and no card.

Paying at https://veezee.io/upgrade credits the same key, trial straight to flex; nothing to reconfigure. Realtime freshness and full pagination come with a paid balance.

Install

Examples below use /all; swap in /linkedin, /reddit, or /x for a single-platform mount.

Claude Code:

claude mcp add --transport http veezee https://mcp.veezee.io/all

Codex CLI:

codex mcp add veezee --url https://mcp.veezee.io/all

Cursor (.cursor/mcp.json or ~/.cursor/mcp.json):

{
  "mcpServers": {
    "veezee": { "url": "https://mcp.veezee.io/all" }
  }
}

VS Code (.vscode/mcp.json):

{
  "servers": {
    "veezee": { "type": "http", "url": "https://mcp.veezee.io/all" }
  }
}

claude.ai: Settings > Connectors > Add custom connector > https://mcp.veezee.io/all (or a single-platform mount).

You can connect any of the clients above before you have a key: OAuth-capable clients sign in on first contact, and the rest get a KEY_REQUIRED error that spells out the mint step, as described in Quickstart; add the Authorization header once you have the key.

More clients (Windsurf, Cline, Zed, plain REST), each snippet verified against the client's official docs: https://veezee.io/docs/clients

REST twin

Every tool has a REST route with identical semantics at https://api.veezee.io (contract: https://veezee.io/openapi.json). A typed TypeScript SDK and CLI ship as @veezee/sdk (docs: https://veezee.io/docs/sdk).

Available Tools

10 tools

get_usageCheck credits and recent chargesA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

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

TDQS

A5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

linkedin_get_companyGet a LinkedIn companyA

Read-only

Inspect

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).

ParametersJSON Schema

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.

Output Schema

ParametersJSON Schema

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

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

linkedin_get_postsGet recent posts by a person or companyA

Read-only

Inspect

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.

ParametersJSON Schema

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.

Output Schema

ParametersJSON Schema

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

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

linkedin_get_profileGet a LinkedIn person profileA

Read-only

Inspect

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.

ParametersJSON Schema

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.

Output Schema

ParametersJSON Schema

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

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

linkedin_search_peopleSearch people on LinkedInA

Read-only

Inspect

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.

ParametersJSON Schema

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.

Output Schema

ParametersJSON Schema

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

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

reddit_get_subredditGet subreddit detailsA

Read-only

Inspect

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.

ParametersJSON Schema

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.

Output Schema

ParametersJSON Schema

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

TDQS

A5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

reddit_resolve_urlIdentify a Reddit URLA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	A Reddit URL, e.g. https://www.reddit.com/r/selfhosted/comments/1tbups6/... or https://redd.it/1tbups6.

Output Schema

ParametersJSON Schema

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

TDQS

A4.6/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

x_get_tweetGet one tweet with full metricsA

Read-only

Inspect

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.

ParametersJSON Schema

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.

Output Schema

ParametersJSON Schema

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

TDQS

A5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

x_get_tweetsGet an account's tweetsA

Read-only

Inspect

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.

ParametersJSON Schema

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.

Output Schema

ParametersJSON Schema

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

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

x_resolve_urlIdentify an X URLA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	An X URL, e.g. https://x.com/nasa/status/2054497961162478079 or https://twitter.com/nasa.

Output Schema

ParametersJSON Schema

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

TDQS

A5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv1.0.1Jul 21, 2026
- Addedlinkedin_get_company
- Removedlinkedin_resolve_url
- Addedlinkedin_search_people
- Removedreddit_get_post
- Addedreddit_get_subreddit
- Removedreddit_get_user
- Addedreddit_resolve_url
- Removedx_get_profile
- Addedx_get_tweets
- Removedx_search
5 tool updatesJul 21, 2026
- Addedlinkedin_get_posts
- Removedlinkedin_search_people
- Addedreddit_get_post
- Addedreddit_get_user
- Removedx_get_tweets
9 tool updatesv1.0.0Jul 21, 2026
- First observedget_usage
- First observedlinkedin_get_profile
- First observedlinkedin_resolve_url
- First observedlinkedin_search_people
- First observedx_get_profile
- First observedx_get_tweet
- First observedx_get_tweets
- First observedx_resolve_url
- First observedx_search

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored 2026-09-09 18:06 across 10 tools

Disambiguation5/5

Each tool maps to a distinct platform, entity, and action. The search-vs-fetch boundaries are explicit, and the singular/plural x_get_tweet vs x_get_tweets pair is clearly differentiated by description.

Naming Consistency4/5

Names broadly follow a snake_case platform_verb_object pattern, and parallel resolvers are consistently named. Minor inconsistencies exist in pluralization (x_get_tweet vs x_get_tweets vs linkedin_get_posts) and get_usage lacks a platform prefix.

Tool Count5/5

Ten tools is within the ideal range, and each tool has a clear purpose. The count fits a multi-platform social data API without feeling bloated or thin.

Completeness2/5

The Reddit and X surfaces are notably incomplete: reddit_resolve_url returns post/comment/user IDs but the corresponding reddit_get_post and reddit_get_user tools are absent, and x_resolve_url references x_get_profile and x_search which are also missing. LinkedIn is better covered, but the multi-platform promise is undermined by these dead ends.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

ZOOQ - LinkedIn Data for AI Agents A
io.github.baldiga
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
Social Media Search Research & Data
451
Social Media Search API — Twitter, Instagram, Reddit, TikTok (XPOZ)AOAuth
ai.xpoz
Twitter/X, Instagram, Reddit & TikTok data for AI agents. Billions of posts. No API keys.
Research & Data Social Media Web Scraping
524
social-dataOAuth
com.superagnt
Live social media data for AI agents: X, LinkedIn, Instagram, TikTok, YouTube, Reddit, Facebook.
Social Media
1
glim.sh A
sh.glim
Give your agent live data from Twitter, Reddit, the web and GitHub. No API keys, no scraping stack.
Browser Automation Social Media Version Control
1434

Related MCP Servers

Veezee Skills MCP Serverofficial
CRM Customer Data Platforms
veezeehq
A
license
Not graded
quality
B
maintenance
Enables AI agents to enrich LinkedIn prospect data with current role, company, and experience through MCP or REST, with credit-metered access and free credits.
Updated 2 months ago (2026-07-21 14:18 UTC)
MIT
Xpoz MCP Serverofficial
Search Social Media Web Scraping
XPOZpublic
A
license
Not graded
quality
B
maintenance
Search Twitter/X, Instagram, Reddit, and TikTok from AI agents. 52 tools for keyword and hashtag search, user profiles, posts, comments, follower connections, and tracking. Billions of posts indexed, natural-language queries, CSV export up to 500K rows. Remote server (Streamable HTTP) with OAuth sign-in, no API keys needed.
Updated 11 days ago (2026-09-09 13:52 UTC)
12
MIT
socialcrawl-mcp
Social Media Search
RidioDevelopment
A
license
A
quality
D
maintenance
Provides AI agents with unified access to 21 social media platforms and 105 endpoints for retrieving profiles, posts, comments, search results, trending content, and analytics without per-platform authentication.
Updated 5 months ago (2026-04-10 13:53 UTC)
4
318 npm
MIT
ZOOQ - LinkedIn Data for AI
Social Media Search CRM
baldiga
A
license
Not graded
quality
B
maintenance
Live LinkedIn data for AI agents: 44 tools for profiles, companies, jobs, posts, people search, job-change signals and email finding. Hosted remote server (streamable HTTP) - your agent never touches your own LinkedIn account. 300 free credits on signup, no card. Dockerfile in repo bridges stdio clients to the hosted endpoint via mcp-remote.
Updated a month ago (2026-08-24 20:29 UTC)
MIT

Veezee MCP server

Run locally (stdio)

Mounts

The 17 tools

Quickstart

Install

REST twin

Links

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Veezee Skills MCP Serverofficial

Xpoz MCP Serverofficial