Enrich Layer MCP Server
OfficialServer Quality Checklist
Latest release: v0.3.0
- Disambiguation5/5
Each tool targets a unique combination of resource (company, person, school, job) and action (lookup, search, profile, count, etc.). Even similar names like enrich_company_lookup, enrich_company_search, and enrich_company_id_lookup are clearly differentiated by input parameters and purpose. No two tools overlap in functionality.
Naming Consistency5/5All tools consistently use the enrich_ prefix followed by a resource type and then a specific action (e.g., enrich_company_lookup, enrich_person_profile, enrich_job_search). The pattern is uniform and predictable, including compound names like enrich_company_id_lookup which follow resource_attribute_action. The naming style is entirely snake_case, with no mixed conventions.
Tool Count4/5While 25 tools is on the heavier side, each tool serves a distinct and necessary function for a comprehensive enrichment API. The breadth is justified by the variety of resources (companies, people, schools, jobs) and operations (lookup, search, profile retrieval, counts, picture fetching, reverse lookups). There is minimal redundancy, so the count feels acceptable rather than bloated.
Completeness4/5The tool set provides comprehensive coverage of the enrichment domain: lookups by various identifiers (name, domain, ID, email, phone), detailed profiles, searches with pagination, employee/student listings, job postings, and credit management. Minor gaps like bulk operations or batch processing are present, but the core functionality is complete and agents can perform all essential enrichment tasks without dead ends.
Average 3.9/5 across 23 of 25 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and openWorldHint, and the description adds the cost of 2 credits and mentions the return of a professional network profile. It does not describe edge cases or side effects, but given the read-only annotation, the description provides adequate transparency for a basic lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence plus a cost note. It is concise, with no redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description and schema cover the mechanics of the call, the description does not explain how this tool differs from the numerous sibling enrichment tools (e.g., enrich_person_search) or when it would be the appropriate choice. It also omits any mention of output format or potential limitations, leaving the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for each parameter are clear and cover all parameters (100% coverage). The description reiterates the key criteria (first name and company domain) but adds no extra depth about how optional parameters like enrich_profile or similarity_checks affect the lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: looking up a person by first name and company domain to find a professional network profile. It is specific about the required inputs, but it does not explicitly distinguish this from sibling tools like enrich_person_search, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling enrichment tools. It does not mention scenarios where this specific lookup is preferred, nor does it explain any prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true, which already inform the agent that this is a safe read operation and may return variable results. The description adds the cost (1 credit) which is a behavioral trait not covered by annotations. However, it does not disclose other behaviors like whether the count is estimated or exact, or how the 'use_cache' parameter affects freshness. Given the annotations cover the safety profile, the description adds some value but not extensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence plus a cost note. It is front-loaded with the main purpose. The cost information is useful and earns its place. No fluff or redundancy. However, it could be slightly more structured by including usage guidance, but for what it is, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 4 with enums, and no output schema, the description is somewhat thin. It does not explain the return format (e.g., just a number or an object), nor does it clarify the meaning of parameters like 'coy_name_match' or 'employment_status' beyond their schema descriptions. The annotations help with safety, but the description could be more complete for a tool with this many options. However, since schema coverage is 100%, the description doesn't need to repeat parameter details, but it could provide more context on how the tool behaves (e.g., what 'estimated_employee_count' means).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 6 parameters have descriptions in the schema. The description itself does not add any parameter semantics beyond what the schema provides. According to the rubric, with high schema coverage, baseline is 3. The description does not compensate with additional context, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the number of employees at a company.' It uses a specific verb ('Get') and resource ('number of employees at a company'), which distinguishes it from sibling tools like enrich_employee_list (which likely returns a list) and enrich_company_profile (which likely returns broader company data). However, it doesn't explicitly differentiate from similar count tools like enrich_job_count, but the resource is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions the cost (1 credit) which is a practical consideration, but does not specify when to use this tool versus alternatives like enrich_employee_list or enrich_company_profile. The context signals show many sibling tools, but the description doesn't offer any comparison or exclusion criteria. The 'at_date' parameter implies historical usage, but this is not explained in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true, which already indicate a safe read operation. The description adds the cost (10 credits per request) which is behavioral context beyond annotations. It also mentions boolean search syntax, which is a behavioral detail. However, it doesn't disclose pagination behavior, rate limits, or what 'enriched' means in terms of data volume. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the main purpose. The cost mention is useful. No fluff. Slightly under-specified but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 2 required, and no output schema, the description is adequate but not complete. It doesn't explain the difference between 'skip' and 'enrich' for enrich_profiles, nor does it explain the page_size limits or resolve_numeric_id. The schema covers these, but the description could add context on when to use enrich vs skip. Also, no output schema means the description could hint at return format, but it doesn't. Overall, it's a minimum viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds the boolean syntax example and cost, but doesn't add much beyond schema. The description mentions 'keyword' and 'company' which map to keyword_boolean and company_profile_url, but the schema already explains those. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches employees by keyword at a specific company, using boolean syntax for job titles. It distinguishes from siblings like enrich_employee_list (which likely lists without keyword search) and enrich_person_search (which may not be company-specific). However, it doesn't explicitly name alternatives, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: search employees at a company with keyword. It mentions cost (10 credits) which is a usage consideration. But it doesn't explicitly state when to use this vs. enrich_employee_list or enrich_person_search, nor does it mention any prerequisites like needing a company profile URL. The cost hint is useful but not a full guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and open-world behavior, so the bar is lower. The description adds the useful 'Cost: 2 credits' detail, but it does not disclose other behavioral aspects such as whether results are capped, how criteria are combined, or what the exact return format is beyond 'number.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences that state the core function and cost with no filler. Every word adds value, and the cost note is a practical detail that would otherwise be missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple count tool with seven optional parameters and no output schema, the description is minimally adequate but leaves gaps: it does not state whether all filters are optional, whether the count is exact or approximate, or describe the response shape beyond 'number.' The strong schema coverage partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter and enum having descriptive text, so the schema carries the semantic load. The description only adds a generic 'matching your criteria' phrase and does not enhance understanding of specific parameters like geo_id or search_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('number of job postings'), making it evident this is a count operation. This distinguishes it from sibling tools like enrich_job_search and enrich_job_profile, which imply list/detail operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like enrich_job_search, nor does it mention exclusions or prerequisites. The only hint is 'matching your criteria,' which implies usage but does not explain scenarios or provide comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds the operational detail of cost: 'Cost: 2 credits,' which is useful. However, it does not disclose output shape, pagination behavior, or edge cases such as empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action, followed by filter categories and cost. Every sentence earns its place, and there is no unnecessary repetition or clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns and any relevant usage constraints. It states it searches job postings and mentions filters/cost, but it doesn't describe the response format or how to combine filters effectively. This is sufficient for basic usage but leaves gaps for an agent deciding how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 7 parameters with descriptions and enums, so the 100% schema coverage sets a baseline of 3. The description loosely maps filters to parameters (company, type, experience level, location), but it adds little beyond the schema and uses vague terms like 'and more.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Search for job postings.' It also enumerates main filter dimensions such as company, type, experience level, and location. However, 'and more' is vague, and the description doesn't explicitly contrast with sibling job tools like enrich_job_profile or enrich_job_count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Search for job postings' implies when the tool should be used, but the description gives no explicit guidance about alternatives or when not to use it. For example, it doesn't mention that enrich_job_profile would be used to get details on a specific job posting. This is acceptable but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds the cost of 3 credits, which is valuable. It doesn't describe other behaviors like rate limits or result format, but given annotations present, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence plus cost. It's front-loaded and easy to parse. Could arguably be a 5, but it does pack the purpose and cost effectively with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with full parameter documentation and read-only annotation, the description suffices. It adds the cost factor and indicates the return type (professional network profile). No output schema, but the description hints at the result. It's complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (100% coverage), and the description doesn't elaborate on them. The cost mention is not parameter-specific. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (look up) and resource (person's professional network profile) keyed by email. It implies a specific use case that differentiates from sibling tools like enrich_reverse_phone, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an email address, but it doesn't specify when not to use it or mention alternative tools for similar lookups (e.g., person_lookup via name). No explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description carries a lower burden for safety. It adds the cost detail ('Cost: 1 credit') which is valuable, but does not describe return format, error handling, or rate limits. This is adequate beyond annotations but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core function and cost with zero waste. Every element serves a purpose, and it is appropriately concise for a simple fetch operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple three-parameter input and no output schema, the description is adequate but minimal. It does not clarify what 'structured data' includes, which could be important for agent expectations. However, with readOnlyHint and the explicit URL input, it is sufficiently complete for a straightforward enrichment tool, though more detail on the return payload would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (url, use_cache, live_fetch) are already documented in the schema. The tool description does not add any additional parameter-specific meaning beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get structured data') and a specific resource ('school profile') sourced from a professional network URL. This distinguishes it from sibling tools like enrich_company_profile or enrich_person_profile, which target different entities, and it is not a tautology of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, exclusions, or when not to use it. While the URL parameter implies usage context, the description does not explicitly address selection criteria among the many sibling enrichment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description aligns with that (Get operation). It adds the cost information (0 credits) but no additional behavioral context such as error handling, URL format, or limitations. With annotations present, the bar is lower, and the description contributes minimally beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that clearly state the purpose and cost. Every word earns its place, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-documented parameter, the description is adequate. It implies the return value (a URL) and is consistent with the annotations. It could explicitly mention output format, but the tool name and purpose make it clear enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter company_profile_url, which is described as 'Professional network company profile URL'. The description does not add any extra meaning beyond the schema, so it meets the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the profile picture URL of a company, using a specific verb and resource. This distinguishes it from sibling tools like enrich_company_profile or enrich_company_lookup, which handle broader company data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It only states the basic function and cost, which does not help an agent decide between this and enrich_company_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already communicate that this is a read-only, open-world operation, so the description does not need to restate that. It adds a useful detail about cost ('Cost: 0 credits') and clarifies the output is a URL, but it does not disclose failure behavior, data source assumptions, or input validation expectations. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no filler or redundancy. It states the purpose immediately and includes the cost detail without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one documented parameter, the description is mostly sufficient: it names the operation, the input, and the output type. It lacks brief usage or limitation context, but given the low complexity and strong schema/annotation coverage, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents person_profile_url with the description 'Professional network profile URL,' giving 100% coverage. The tool description adds no additional parameter semantics such as expected URL format, domain restrictions, or validation rules, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the profile picture URL of a person.' It uses a specific verb and resource and explicitly identifies the return value as a URL, distinguishing it from sibling tools like enrich_person_profile or enrich_person_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With many sibling person/company enrichment tools present, the agent gets no contextual direction about prerequisites, appropriate inputs, or cases where another tool would be more suitable.
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?
The annotations already declare readOnlyHint and openWorldHint, covering safety and data completeness. The description adds valuable behavioral context: cost (3 credits per employee returned) and the type of data returned (profile URLs and basic info). However, it does not mention pagination, caching, or other runtime behaviors beyond what is in param descriptions, but the added cost detail is notable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that state the action, return type, and cost. No wasted words, front-loaded with the primary purpose. It communicates everything necessary in minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 10 parameters and no output schema, the description is very brief. It does not explain the output format (e.g., pagination, fields), or offer usage examples. While param descriptions cover individual parameters, the overall operational context is thin. The read-only and open-world annotations help, but for a tool with this many options, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 10 parameters are documented with descriptions and enums. The tool description itself adds no parameter-specific meaning beyond the high-level purpose. Baseline for high coverage is 3, and the description does not enhance or clarify any parameter semantics further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists employees of a company and returns profile URLs and basic info. It uses a specific verb ('List') and resource ('employees of a company'), and distinguishes from sibling tools like enrich_employee_search (search) and enrich_employee_count (count) by its focus on listing all employees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks mention of use cases, prerequisites (like needing a company URL), or exclusions. No comparison with sibling tools like enrich_employee_search is offered, so an agent may not know if this is the best choice for a given scenario.
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 declare readOnlyHint=true and openWorldHint=truetas, so the read-only and open-world aspects are covered. The description adds the cost (1 credit per email) and the requirement of at least one input URL, which are behavioral directives not in the schema. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no fluff. Front-loaded with the action and then requirements. Every sentence adds information: purpose, input requirement, cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential usage (input requirement) and cost. It doesn't elaborate on return format, but given no output schema and simple purpose, it's sufficient. Missing mention of pagination or handling of multiple emails, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for all 5 parameters. The description adds the crucial constraint that at least one of profile_url, twitter_profile_url, or facebook_profile_url must be provided, which is not evident from the schema alone (since all are optional). This adds significant usage semantics beyond the per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get personal email addresses of a person'. It specifies the resource (personal email addresses) and the action (get). It doesn't explicitly differentiate from sibling tools like 'enrich_work_email' or 'enrich_personal_contact', but the resource is specific enough to be distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description tells the user what input to provide, but doesn't explain when to choose this over enrich_work_email or enrich_person_lookup. It lacks any exclusions or alternative references.
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?
The description discloses additional behavioral details beyond the readOnlyHint annotation: it mentions a cost of 3 credits per URL returned, pagination via page_size and next_token, and that it returns professional network URLs. This adds transparency about side effects and output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the main purpose, then mentions the output type, cost, and pagination. There is no redundant or filler content, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 24-parameter schema and lack of output schema, the description covers cost and pagination but does not explain the structure of the returned company data or the impact of the enrich_profiles parameter. It leaves gaps about what exactly is returned beyond URLs and counts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 24 parameters (100% coverage). The tool description does not add any additional meaning to the parameters; it only refers to them generally as 'various criteria'. Since schema coverage is high, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for companies by various criteria including location, industry, size, funding, and more, and mentions it returns professional network URLs. This distinguishes it from sibling lookup or profile tools that are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for searching companies by criteria, but does not explicitly state when to use it over alternative tools like enrich_company_lookup or enrich_company_profile. It lacks clear when-to-use or when-not-to-use guidance.
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 provide readOnlyHint: true and openWorldHint: true. The description adds cost information ('Cost: 3 credits') and clarifies the lookup behavior. It does not contradict annotations and provides additional context beyond the safe-read nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a cost note, front-loaded with the core purpose. Every word contributes value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify return values. It implies the result is the person holding the role, but does not specify whether it returns a list, profile details, or just contact information. While annotations cover safety, the missing output detail leaves some gaps for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as each parameter has a description (e.g., 'Role to look up, e.g. ceo', 'Name of the company'). The description does not add further parameter details beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Look up a person by their role at a company. Find who holds a specific title at a given company.' The verb 'look up' and resource 'person by role' are specific, and it distinguishes from sibling tools like enrich_person_lookup or enrich_company_lookup by focusing on role-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (when you need to find a person by title at a company) but does not explicitly contrast with alternatives such as enrich_person_lookup or enrich_employee_search. There is no explicit when/when-not guidance or mention of alternative tools.
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 declare readOnlyHint and openWorldHint. The description adds useful behavioral context: the credit cost per student and that it returns profile URLs and basic info. It does not contradict annotations and enriches the disclosure beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, direct sentences. Every word earns its place, with the main action front-loaded and no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 4 enums, and no output schema, the description is somewhat sparse. It doesn't explain the credit model for enrich_profiles or pagination, but the tool is a straightforward list operation. Adequate for basic understanding, but gaps remain 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'basic info' and 'profile URLs' but does not add parameter-level meaning or clarify things like enrich_profiles implications or page_size behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List students of a school' with a specific verb and resource, and adds return content ('profile URLs and basic info') that distinguishes it from siblings like enrich_employee_list or enrich_school_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (need a school context, implied by 'of a school' and required school_url parameter) but provides no explicit when-to-use guidance or comparison to alternatives. No exclusions or conditions are mentioned.
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 indicate read-only and open-world behavior. The description adds the cost (0 credits) and specifies the output (professional network URL), which goes beyond the annotations. No side effects are described, but the readOnlyHint covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, directly conveying the purpose, input, and output. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of a single-ID lookup and the lack of an output schema, the description sufficiently covers what the tool does and what it returns (URL). Mention of cost adds context. It does not discuss error cases, but that is not required for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'id' with a clear description and example. The tool description reiterates the same information without adding new semantic nuance, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (look up) and target (company by internal numeric ID), and specifies the output (professional network URL). It is unambiguous and distinct from sibling tools like enrich_company_search or enrich_company_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a company ID, and mentions cost (0 credits), but does not explicitly compare to alternatives or state when to prefer this over other tools. Usage guidance is implied rather than explicit.
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?
The description aligns with annotations, indicating a read-only operation without side effects. It additionally notes that it costs 0 credits, providing cost transparency beyond the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single clear sentence. It includes essential information (what it does and cost) without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and cost, which is sufficient for a simple balance check. It does not elaborate on output format, but given the simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters to describe, so schema coverage is effectively complete. The description does not add parameter-specific information because none exist, aligning with the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's function as viewing the current credit balance, using the verb 'View' and specifying the resource. This distinguishes it from sibling enrichment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as checking balance before running enrichment. It is implied but not stated; no explicit comparison to sibling tools is provided.
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 communicate read-only and open-world nature, so the description does not need to restate safety. It adds meaningful behavioral context by disclosing the credit cost (2 credits) and summarizing the returned fields. It does not cover error cases, but for a simple, read-only enrichment tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with front-loaded purpose and no wasteful text. It conveys what the tool does, what it returns, and its cost in a compact and readable way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no nested objects), the description is mostly sufficient: it states the source URL, key return fields, and cost. The absence of an output schema is mitigated by listing example fields, though 'and more' is vague and no URL formatting details are included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the only parameter 'url' as a 'Professional network job posting URL' at 100% coverage. The description reinforces the URL-source concept but does not add additional parameter syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get structured data of a job posting from its professional network URL.' It clearly differentiates this tool from the many sibling enrichment tools focused on companies, people, schools, or job searches. It also lists concrete returned fields like job title, description, company, and location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when a professional network job posting URL is available, but it does not explicitly state when to avoid it or mention alternatives. With 24 sibling tools, some explicit contrast with enrich_job_search or other lookup tools would improve guidance.
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?
The readOnlyHint annotation already covers safety, and the description adds useful behavioral context beyond it: the lookup returns a professional network URL and costs 2 credits. It does not describe edge cases like not-found results or the exact effect of the enrich_profile parameter, but overall it is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, front-loaded with the primary action and output, followed by the essential input prerequisite and cost. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with rich parameter schema and readOnly annotation, the description covers the main output, the input prerequisites, and cost. It could still explain optional enrich_profile behavior or fallbacks when the company is not found, but the overall context is adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description is 100% and each parameter already has a provided explanation. The description adds an important condition not encoded in the schema: at least one of company_name or company_domain must be provided. This genuinely helps an agent choose the right parameter combination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Look up a company'), identifies the required input type ('by name or domain'), and states the expected output ('professional network URL'). This clearly differentiates it from sibling tools like enrich_company_search or enrich_company_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear condition for the call ('Provide at least one of company_name or company_domain') and notes the cost. However, it does not explicitly say when to prefer this tool over alternatives such as enrich_company_id_lookup or enrich_company_search, so usage context is mostly implied.
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 indicate readOnlyHint and openWorldHint. The description adds a behaviorally relevant cost ('3 credits') but does not describe the return payload or failure modes; this is acceptable for a simple read-only lookup with strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One clear, front-loaded sentence conveys purpose, input, and cost with no filler. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only lookup with full schema coverage and annotations, the description is largely sufficient. It lacks explicit return structure, but 'professional network profile' gives a reasonable expectation of the output, and the tool is simple enough that this does not feel incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents phone_number with E.164 formatting and an example, so the description does not need to add much. The description only restates 'phone number' in natural language, adding no meaningful semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Look up'), the target resource ('a person's professional network profile'), and the input ('phone number'). This distinguishes it from sibling tools like enrich_reverse_email and enrich_person_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by their phone number' clearly signals when to use this tool: when a phone number is the available identifier. It does not explicitly name alternative tools or list exclusions, but the trigger condition is clear.
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?
The annotations already mark the tool as read-only, so the description is not burdened with repeating that. It adds meaningful behavioral context by stating the cost is 3 credits, which is useful for an agent deciding whether to invoke the tool. It does not mention async behavior when callback_url is supplied, but that is already described in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence that states the purpose and the cost. Every word is informative and there is no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with a single required input and no output schema, the description is sufficiently complete. It states the input, the outcome, and the cost, while the schema covers the callback behavior and the annotation covers the read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters already have clear descriptions, so the baseline of 3 applies. The description reinforces that profile_url is a professional network profile URL but does not provide additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear output ('work email address') and input source ('professional network profile URL'). It distinguishes itself from sibling tools like enrich_personal_email and enrich_reverse_email by specifying 'work' email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the primary use case: given a person's professional network profile URL, retrieve their work email address. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough to guide tool selection.
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 declare readOnlyHint=true, and the description aligns by saying 'Get.' It adds cost ('1 credit per contact number') and input precondition, which are valuable beyond annotations. It does not disclose pagination behavior, but page_size is in the schema, so this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then input requirement and cost. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only enrichment tool with no output schema, the description covers purpose, input constraints, and cost. It doesn't explain return values or errors, but given the schema and annotations, the agent has enough to invoke correctly. Lacks explicit sibling differentiation, but the name and purpose are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that at least one of the three profile URL parameters must be provided, and that the cost is per contact number. This relationship is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('personal contact phone numbers of a person'), distinguishing it from sibling tools like enrich_personal_email and enrich_reverse_phone. The input requirement is also stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the required condition: 'Provide at least one of: profile_url, twitter_profile_url, or facebook_profile_url.' It also mentions cost. However, it does not explicitly compare to alternatives or state when not to use this tool, so a 4 rather than 5.
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 declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds non-annotation behavior: the requirement of exactly one URL, the return contents, and the credit cost. It does not contradict annotations and provides useful extra context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then the key constraint, then output, then cost. No redundancy, every sentence earns its place. Perfectly sized for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists returned data categories ('experience, education, skills, and more') which sets expectations. Combined with 100% schema coverage for parameters and annotations for read-only/open-world, the description is sufficiently complete for an 8-parameter tool, though it omits potential pagination or error behavior—not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds the critical constraint of supplying exactly one of the three URL parameters, which is not in the schema. This is essential for correct invocation, raising the score above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get structured data') and resource ('person profile'), and specifies the output ('experience, education, skills, and more'). It distinguishes from sibling tools like enrich_person_lookup by emphasizing the URL-based input and richer data, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite: 'Provide exactly one of: profile_url, twitter_profile_url, or facebook_profile_url.' This tells the agent when to use it (when a profile URL is available). It also mentions the cost (1 credit), implying selective use. Does not explicitly list when not to use alternatives, but the input constraint is strong guidance.
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 significant behavioral details beyond the annotations (readOnlyHint, openWorldHint): it discloses the cost model ('3 credits per URL returned'), pagination behavior ('Returns up to page_size results (max 100) per call'), and the presence of next_page URLs and total_result_count. This is valuable operational information not present in the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it states the purpose first, then output, cost, and pagination. Each sentence earns its place without fluff or redundancy, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the high parameter count (28) and no output schema, the description covers essential operational aspects: purpose, output type, cost, and pagination mechanics. However, it omits boolean search syntax and does not clarify whether at least one filter is required, which are notable gaps for a search tool with many optional filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a high-level overview of criteria categories ('name, location, education, role, company, and more') and explains pagination parameters, but it does not elaborate on boolean search syntax or how multiple criteria combine. Most parameter-level meaning is already in the schema descriptions, so the added value is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and identifies the resource ('people') with a clear scope ('by various criteria including name, location, education, role, company, and more'). It also mentions the output ('professional network URLs'), which helps distinguish it from sibling tools like enrich_person_lookup or enrich_employee_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need to search for people by criteria. It does not explicitly name alternatives or provide when-not-to-use guidance, but the 'Search for people' phrasing is a strong indicator of its use case. Cost and pagination details further clarify usage expectations.
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 and openWorldHint. The description adds severe value by disclosing the cost model ('Cost: 1 credit', plus extra credits for parameters), cache behavior, and a hint that include/exclude toggles for enriched data. This exceeds the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, highly scannable: first states the primary function and output; second discloses cost. No wasted words; every phrase is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only enrichment tool, the description, annotations, and comprehensive schema fully specify inputs, output expectations (structured data including profile fields), and pricing. No fidelity gaps beyond what's needed—no output schema exists but it's mentioned return is 'more' as a hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Param schema has 100% coverage with detailed descriptions for each parameter, including enum values and cost implications. The description reinforces the semantics by noting that several parameters cost extra credits, aligning with the cost disclosure. Though the description itself doesn't add param detail, with full schema coverage, the burden is already met; plus it adds credit-cost transparency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is clear: 'Get structured data of a company profile from its professional network URL.' The specific verb 'Get' + resource 'structured data of a company profile' is distinguishable from siblings like enrich_company_lookup, though it doesn't explicitly name a sibling alternative—however, 'professional network URL' and the context fixate on URL-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is given: requires a professional network URL, and it returns structured profile data. No explicit mention of when not to use it compared to alternatives like search or ID lookup, which would have earned a 5. The sibling list suggests alternatives exist but they're not named in the text.
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 aligns with the readOnlyHint annotation ('Check' implies no side effects) and adds cost information, providing transparency without contradicting 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states purpose and cost, with no irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple check operation, the description fully covers functionality, parameter, and cost. No output schema is needed for such a straightforward boolean check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'email' is fully described with a clear example, and the schema coverage is 100% (only one parameter), so the description adds necessary clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check if an email is from a disposable email provider') and the specific resource, distinguishing it from sibling tools that handle companies, schools, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly indicates when to use (checking disposable email) and includes a cost mention ('0 credits'), providing clear usage context. Alternatives are implied by the distinct purpose.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/enrichlayer/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server