Veezee

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct platform (LinkedIn vs X) and action (profile, search, resolve URL, get tweet/tweets). No overlap in functionality, and get_usage is clearly separate for credit/plan information.
Naming Consistency5/5
All tools follow a consistent pattern of lowercase underscore naming: <platform>_<action>_<object> or <platform>_<action>. Examples: linkedin_get_profile, x_search, x_get_tweets. No deviation.
Tool Count5/5
9 tools cover two social media platforms plus usage checks. This is a well-scoped number, neither too few nor too many for a specialized data retrieval server.
Completeness3/5
The X platform is well-covered with profile, tweets, tweet, and search. However, LinkedIn lacks tools for companies and posts, which are mentioned in descriptions but not implemented. This creates notable gaps for a comprehensive LinkedIn data surface.
Average 4.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on July 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true. Description adds significant behavioral context: free, exempt from rate limit, works across account types, includes upgrade_url, manage_url, claim_url. 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?
Description is informative but slightly long. Each sentence adds value: purpose, cost, usage guidance, response details, caveat. Could be more concise but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no parameters, simple. Description covers output (charges, URLs), usage scenario, and account types. Has output schema to fill remaining details. Complete enough for reliable 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?
No parameters. Schema coverage 100% trivially. Description adds no param info but none needed. Baseline for 0 params is 4.
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?
Description clearly states tool checks balance, plan, limits, and last 10 charges. Verb 'check' is specific. Explicitly distinguishes from sibling tools by stating 'Not for fetching platform data', which are social media tools.
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?
Provides strategic guidance: 'call it first to check your budget before running data tools, and any time after'. Notes it costs 0 credits and exempt from rate limit. No direct alternatives among siblings, so no when-not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds valuable behavioral context: credits cost (4 per page), realtime option with surcharge, domain resolution credit refund, pagination via cursor, and return fields. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with clear sections. Each sentence adds value. Could be slightly more concise but still effective.
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, description thoroughly covers pagination, credits, entity resolution, and usage scenarios. It provides complete context for an agent to select and invoke correctly, including limitations and alternatives.
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%, so baseline is 3. Description adds meaning beyond schema: explains identifier types (URL, slug, URN, domain) and company resolution behavior; clarifies freshness enum behavior and trial restrictions; explains max_credits as a ceiling. Notably enhances clarity.
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 recent LinkedIn posts of a person or company. It distinguishes from sibling tools like linkedin_get_company by referencing domain resolution behavior and explicitly stating what it is not for (reading single post, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this for what has X been posting, voice-of-company research, or activity checks before outreach.' Also states when not to use: 'Not for reading one specific post you already have a URL for, and not for keyword search across LinkedIn.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description expands significantly beyond annotations (readOnlyHint, openWorldHint). Discloses credit costs (10 + 1 per 10 results), pagination pricing, limit restrictions, freshness behavior, company matching details, and anonymous profile handling. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but each sentence adds value. It is front-loaded with main purpose and key usage. Could benefit from slightly more structured formatting (e.g., bullet points), but the information density is high and scannable.
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 params, credit system, fuzzy matching), the description covers input guidance, parameter interactions, cost model, limit constraints, output fields, and post-processing advice. The output schema is referenced but description already states return fields, making it complete for correct invocation.
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?
Even with 100% schema coverage, the description adds substantial meaning: explains parameter interactions (e.g., keywords derived from name/title, school/company rejection), accepted forms for company filters, credit cost implications, and freshness behavior. 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?
Description explicitly states purpose: 'Find people on LinkedIn by keywords and filters.' It distinguishes from sibling tools by specifying when to use it (without a profile URL) vs. linkedin_get_profile. Clear verb (find/search) and resource (people on LinkedIn).
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 when-to-use ('right tool... without a profile URL'), when-not-to-use (avoid combining past_company name with limit=30, don't pass anonymous profiles to get_profile), and alternatives (use linkedin_get_profile for known URL). Also explains cost implications and parameter constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost structure (base 4 credits, extra sections, realtime surcharge), caching behavior, trial key limitations, and spending ceiling. These details go well beyond the readOnlyHint and openWorldHint annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds essential information, front-loaded with purpose and identifier details, then returns, costs, usage guidance. No redundancy or wasted words.
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 identifier, return overview, sections, costs, caching, limitations, and relationships to sibling tools. With a detailed output schema present, return value explanation is unnecessary. Complete for a tool of this complexity.
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 significant explanation beyond schema: identifier formats and auto-cleaning, sections cost rules, freshness options with trial key behavior, and max_credits as a safety ceiling. Schema coverage is 100% but description enriches each parameter's meaning.
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 'Fetch one person's LinkedIn profile' with specific identifier formats, distinguishes from linkedin_search_people and linkedin_get_company. Verb+resource is precise.
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 guides to use linkedin_search_people for name-only queries, warns that anonymous search results cannot be fetched, and redirects company queries to linkedin_get_company. Provides clear when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![veezee-mcp MCP server](https://glama.ai/mcp/servers/veezeehq/veezee-mcp/badges/card.svg)](https://glama.ai/mcp/servers/veezeehq/veezee-mcp)

Score Badge

Copy to your README.md:

[![veezee-mcp MCP server](https://glama.ai/mcp/servers/veezeehq/veezee-mcp/badges/score.svg)](https://glama.ai/mcp/servers/veezeehq/veezee-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/veezeehq/veezee-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server