Veezee: LinkedIn people & company data for agents
Server Details
LinkedIn data for AI agents: structured profiles, people search, companies, and posts over MCP or REST. 500 free credits, no card.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.9/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: get_company for company info, get_profile for person, get_posts for posts, search_people for search, resolve_url for URL identification, get_usage for account status, and provision for account creation. No overlaps or ambiguity.
All tool names follow a consistent snake_case verb_noun pattern (get_company, get_profile, search_people, resolve_url, etc.) with no mixing of conventions or irregular verbs.
7 tools is well within the optimal 3-15 range. Each tool addresses a core need for LinkedIn data access and account management without redundancy or unnecessary complexity.
Covers the main LinkedIn data retrieval operations: company, profile, posts, and search. Minor gap: no tool to fetch a specific post by URL (only posts by entity). The domain resolution workaround for company search is acceptable but slightly indirect.
Available Tools
7 toolsget_companyGet a LinkedIn companyARead-onlyIdempotentInspect
Fetch one company's LinkedIn page: name, description, industry, employee count, headquarters, website, founding year, specialities, and the URN/numeric id you need for 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. This tool does not search by name: if you only have an approximate company name, use search_people's current_company filter with keywords (the filter resolves names) or give the exact slug. For the company's posts, use 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). | 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 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent, but the description adds significant beyond: domain resolution costs, refund policy, error behavior (INVALID_INPUT with closest matches), freshness parameter pricing, and that numeric ids/URNs are not accepted. 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?
The description is comprehensive but relatively long. However, every sentence serves a purpose, and key information is front-loaded. Could be slightly more concise, but the structure is clear and logical.
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 (pricing, domain resolution, error handling, freshness, identifier types), the description covers all aspects. An output schema exists, so return values are not needed. The description is complete for an AI 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%, baseline 3, but the description adds substantial meaning: for identifier, it explains acceptable types (URL, slug, domain) and explicitly states what is not acceptable; for freshness, details caching and pricing; for max_credits, explains its role as a ceiling. Adds value 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 it fetches one company's LinkedIn page and lists specific fields like name, description, industry, employee count, etc. It distinguishes from siblings by explicitly noting that this tool does not search by name, and directs users to search_people or get_posts 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?
Provides explicit guidance on when to use this tool versus siblings: not for name search, use search_people's current_company filter or exact slug for approximate names; for posts, use get_posts. Also explains that numeric ids/URNs are not fetchable identifiers. Includes credit cost and domain resolution behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_postsGet recent posts by a person or companyARead-onlyIdempotentInspect
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 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). | 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: cost (4 credits per page), freshness surcharge, domain resolution behavior with refund mechanism, and identifier type handling. 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?
Six dense sentences with no wasted words, front-loaded purpose, clear structure covering all key aspects without 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?
With output schema present, description covers return fields, pagination cursor, credit costs, freshness, identifier nuances, and limitations. Fully adequate for agent decision-making.
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?
All 4 parameters have schema descriptions, but the description adds deeper meaning: identifier format variations, auto-detection, domain credit behavior, freshness options, and max_credits as ceiling.
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 'fetch the recent LinkedIn posts of one person or one company', specifies identifier types, and distinguishes from siblings by excluding reading a specific 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?
Explicitly provides when to use ('what has X been posting', voice-of-company research, activity checks) and when not to (not for specific post or keyword search), with clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_profileGet a LinkedIn person profileARead-onlyIdempotentInspect
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 search_people first; this tool does not search. Results from search_people with is_anonymous=true cannot be fetched here; treat them as 'someone matching this exists' and stop. Companies belong to 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). | 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses credit costs, return overview and sections, caching behavior via freshness parameter, automatic URL cleaning, and constraint on anonymous results. Annotations already indicate read-only, open-world, idempotent; description adds rich context without 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 dense but logically flows from purpose to identifier to returns to credits to usage hints. Could be slightly more structured (e.g., bullet points) but every sentence adds 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 essential aspects: what it returns, credit costs, parameter behavior, edge cases, and integration with sibling tools. Given the output schema exists to detail return fields, the description is complete for effective 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%, but description adds significant meaning: explains identifier formats, freshness options with credit implications, max_credits ceiling behavior, and sections credit structure. 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 action 'Fetch one person's LinkedIn profile' and specifies the resource. It distinguishes itself from siblings by explicitly noting that search_people is for names and get_company is for companies.
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 when you have a profile identifier, and if only a name use search_people first. Also addresses edge cases like anonymous search results and redirects to get_company for companies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageCheck credits and recent chargesARead-onlyIdempotentInspect
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 whenever you need to budget. 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 creating an account (provision) or fetching LinkedIn data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: zero cost, rate limit exemption, and URLs for human actions (upgrade_url, manage_url, claim_url). Annotations already indicate read-only and idempotent, but description supplements with practical details.
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?
Four well-structured sentences, front-loaded with core purpose. Every sentence adds distinct value, 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 0 parameters, rich annotations, and presence of output schema, description covers usage, behavioral traits, and actionable URLs. Fully adequate for an agent to invoke 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?
Tool has no parameters, so parameter semantics are not needed. Schema coverage is 100%, and description adds no param info but provides context about returned data (balance, charges, URLs). Baseline 4 is appropriate.
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 clearly states it checks balance, plan, limits, and last 10 charges. Distinguishes from siblings by explicitly stating it is not for creating accounts (provision) or fetching LinkedIn data.
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: 'call it whenever you need to budget.' Also notes it costs 0 credits and is exempt from rate limit. The 'not for' statement provides clear exclusions, though it could reference sibling tools more explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
provisionCreate a free trial accountAInspect
Create a free trial account and get an API key, no signup and no card. Call this first if you have no key: you get 500 free credits. Over MCP, later calls in this same session authenticate automatically; over REST, send the key as 'Authorization: Bearer ' on every call. The response includes the api_key (shown exactly once, so store it) and a claim_url that attaches your human's email so the account can be recovered if the key is lost. Costs 0 credits. Trial limits: 1 concurrent call, 20 calls/minute, search capped at 10 results per call, 5 realtime fetches total. Not for checking your balance: that is get_usage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses costs (0 credits), trial limits (concurrent calls, rate, search cap, realtime fetches), and response behavior (api_key shown once, claim_url for recovery). No annotations beyond openWorldHint, so description fully covers behavioral traits.
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 appropriately sized, front-loaded with purpose and key instructions. Each sentence adds value (authentication, limits, exclusions). No redundancy or 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?
Covers all necessary context: when to call, how to authenticate, what response contains (api_key, claim_url), limitations, and cost. Output schema exists, so return values are not required but are summarized. Complete for a no-input creation 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?
Input schema is empty, and the description confirms no user input is needed ('no signup and no card'), adding clarity beyond the schema. Baseline for 0 params is 4, but the description provides helpful context, warranting a 5.
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 'Create a free trial account and get an API key', using specific verbs and resource. It distinguishes from siblings by noting 'Call this first if you have no key' and explicitly contrasting with get_usage for balance checking.
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: 'Call this first if you have no key'. Also gives context for authentication methods (MCP vs REST) and excludes use cases: 'Not for checking your balance: that is get_usage'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_urlIdentify a LinkedIn URLARead-onlyIdempotentInspect
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 get_profile or get_posts. For companies, use the returned HANDLE with get_company or get_posts; the company URN/id is a search_people filter input, not a fetch identifier. Costs 2 credits. Skip this tool when you already have a slug, URN, or clean URL: get_profile and 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. |
Output 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent. Description adds cost (2 credits), error behavior for non-LinkedIn URLs, and explains the structure of the return object, which is beyond 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 thorough but slightly verbose; however, it is well-structured with clear sections and front-loaded purpose. Every sentence adds 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?
Given the output schema exists, the description explains the return fields and how to use them with sibling tools, covering complexities like stable URNs and company handle usage.
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% for the single 'url' parameter. Description adds value by specifying acceptable URL formats (with utm params, subdomains, trailing slashes) and that non-LinkedIn URLs result in INVALID_INPUT.
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 identifies what a LinkedIn URL points to (profile, company, post) and distinguishes it from siblings by specifying it resolves URLs when the target type is unknown.
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 (any LinkedIn URL) and when to skip (if you already have slug, URN, or clean URL, and for non-LinkedIn URLs). Provides alternative tools: get_profile and get_company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_peopleSearch people on LinkedInARead-onlyIdempotentInspect
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; names are resolved 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 company NAME filter with limit=30: name resolution spends one of the call's three internal fetches, so that combination is rejected. With a company name keep limit<=20; for limit=30 pass the company's numeric id or URN (get_company returns both). 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 get_profile. For one known person with a URL/slug, call 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). | 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. | |
| current_company | No | Company name, slug, numeric id, or urn:li:fsd_company URN. |
Output 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds extensive behavioral context beyond annotations: credit costs (10 initial + pagination), cursor pricing model, maximum limits, company name resolution, is_anonymous=true handling (do not pass to get_profile), freshness parameter behavior (cached vs realtime with credit refund). No contradiction with readOnlyHint, idempotentHint, 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?
Front-loaded with purpose. Slightly long but justified by complexity (11 params, pricing, pagination). Every sentence adds value; no redundancy. Could be trimmed slightly but appropriately sized for the tool's sophistication.
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 critical aspects: purpose, when to use, parameter semantics, credit costs, pagination, edge cases (company name limit, private profiles), output fields (name, position, etc.), and sibling comparison (get_profile). Given the tool's complexity and the presence of output schema, description is fully self-contained.
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 significant meaning beyond 100% schema coverage: explains keywords derivation from name/title filters, company filter accepted forms ('name, slug, numeric id, or URN'), freshness cache vs realtime credit cost, max_credits as spending ceiling, limit/company name interaction. Schema defines basics; description enriches with usage context.
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?
Clear verb+resource: 'Find people on LinkedIn by keywords and filters.' Explicitly distinguishes from get_profile by stating to use get_profile for a known person with URL/slug. Provides specific use cases like 'name, role, or who is the X at Y question without a profile 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?
Provides explicit when-to-use (keyword-based search) and when-not-to-use (known person with URL: use get_profile). Gives detailed constraints: school/company filters alone rejected, company name with limit=30 rejected, recommends larger limit over pagination. Compares with sibling get_profile directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!