NeuralVerge MCP Server

Official

by neuralverge

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Multiple tools target similar actions (email finder vs LinkedIn email, people vs company employee search, phone vs US phone enrichment), and async workflows (research vs agent) are easy to confuse. Descriptions help clarify, but boundaries between tools are not always sharp.
Naming Consistency3/5
Strong run_ prefix creates a consistent feel, but suffixes mix verb-style (search, extract) and noun-style (email_finder, phone_enrichment_us) naming. The outlier get_session_status breaks the run_ pattern, and run_linkedin_domain is misleading (it does not search by domain).
Tool Count4/5
With 16 tools, this is slightly above the typical 3-15 range, but the server covers distinct domains (research, search, LinkedIn, email, phone, Crunchbase), so each tool earns a place. The count feels justified for a comprehensive enrichment platform, though it borders on heavy.
Completeness4/5
Core data retrieval surfaces are well covered: research workflow, search, extraction, LinkedIn, email, phone, and company data. Notable gaps include no agent management (list/create agents) and no session control (cancel/pause), but most practical workflows are supported.
Average 3.8/5 across 16 of 16 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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.json to 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the high-level outcome and does not mention what happens when no email is found, whether the result is verified, limitations, rate limits, or any other behavioral details an agent would need to handle edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no filler. Every word earns its place, and it is appropriately concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple lookup nature and complete schema, the description covers the basic purpose and inputs. However, since there are no annotations and no output schema, it omits return-value details and not-found or error behavior, leaving some ambiguity for an agent choosing and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description merely restates 'company domain, first name, and last name' without adding extra format details, constraints, or relationships beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Finds') and a clear resource ('a professional email address for a person'), and lists the three required inputs. It clearly communicates the tool's function, but it does not explicitly differentiate from similar sibling tools like run_email_enrichment or run_linkedin_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives such as run_email_enrichment or run_email_validation. The phrase 'given their company domain, first name, and last name' implies a precondition, but there are no explicit use cases, exclusions, or alternative recommendations, which is a significant gap given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'when available', indicating that data may not always be present, but does not disclose any other behavioral traits such as data sources, rate limits, or error handling for invalid numbers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and front-loaded sentence. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the core functionality and lists expected data fields. It could mention behavior when no data is found, but 'when available' partially addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the only parameter fully (phone number in international format). The description adds minimal extra meaning beyond the schema, essentially restating that the number is 'known' without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('enriches') and resource ('known phone number'), and lists the associated profile data types. It clearly states the tool's function, but does not explicitly differentiate from the sibling tool 'run_phone_enrichment_us', so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use when you have a known phone number and want associated profile data. However, there is no explicit guidance on when not to use it or how it differs from siblings like 'run_phone_enrichment_us'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It notes data is returned 'when available', but does not state whether the operation is read-only, requires special authentication, can fail for invalid/disposable emails, or what side effects (if any) occur. This opacity could lead an agent to misuse the tool or misinterpret errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys purpose and key data fields without excess words. No fluff or repetition—every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core function and expected outputs, but with no output schema and no annotations, it omits return format (e.g., JSON structure), error behavior for invalid emails, and any rate-limit or permission notes. Given the tool's simplicity (one parameter), this is sufficient but not rich; there is clear room for additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the sole parameter 'email' with a clear description. The tool description adds only the qualifier 'known' and the list of profile data, which does not materially enhance parameter understanding beyond the schema. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Enriches') and resource ('known email address'), and enumerates the exact data returned (name, phone, company, position, LinkedIn/X profiles). This distinguishes it from sibling tools like run_email_validation (validates) and run_email_finder (finds), making its 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you already have a known email and want associated profile data. However, it does not explicitly contrast with alternatives (e.g., run_email_finder when you lack an email, run_phone_enrichment for phone-only data) or state when not to use it. The context is clear but under-specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Searches' with no details on output, authentication, rate limits, or side effects. This is a minimal disclosure for a tool that likely performs network requests and returns data, so significant behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly one sentence, front-loaded with the primary action, and every phrase adds meaning. The reference to the sibling tool is concise and avoids repeating filter names. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, no output schema, and no annotations, the description is far too sparse. It doesn't mention required vs optional fields, result format, or any usage examples. The only context is the link to run_linkedin_people_search, which is helpful but insufficient for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, so the description should compensate by explaining parameters. It only mentions 'one or more given companies' (covering the required companies param) and vaguely references 'people-style filters' without listing any specific filter names or meanings. This does little to help an agent select parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Searches'), a clear resource ('LinkedIn employees of one or more given companies'), and explicitly distinguishes itself from the sibling run_linkedin_people_search by scoping to companies. The phrase 'using the same people-style filters' further clarifies it's a variant of people search, not a general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description defines when to use this tool: when you need employees of specific companies. It references run_linkedin_people_search to indicate filter compatibility, implying an alternative for general people searches. However, it does not explicitly state exclusions or when not to use it, so it misses a complete when/where-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'searches', implying a read-only operation, but does not disclose pagination behavior, scraper depth implications, authentication needs, or return format. This is minimal transparency for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that captures the core function and key filter dimensions. It is front-loaded with the action and resource, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and no annotations. The description is brief but covers the main purpose. However, it omits behavioral context such as pagination, result format, and how parameters like scraperMode affect behavior, making it only partially complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured schema already explains all parameters. The description adds a high-level summary (size, industry, location) that maps to specific parameters but does not add new semantic detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches LinkedIn companies using a text query with optional filters (size, industry, location). It uses a specific verb and resource, and the mention of size/industry/location distinguishes it from sibling tools like people search and company 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a company search is needed, but it provides no explicit timing guidance or alternatives. It does not mention when not to use this tool or point to sibling tools, so usage is inferred rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool 'searches' and does not mention output format, pagination, rate limits, authentication needs, or whether the operation is read-only. This is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the main action and scope. It contains no redundant information and is appropriately concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters), lack of annotations, and absence of an output schema, the description is far too thin. It does not explain how results are returned, how filters interact, what the pagination behavior is, or any other details that would help an agent use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 17 parameters with only 24% description coverage. The description adds a general 'rich set of advanced filters' and lists a few categories (company, title, seniority, location, experience, industry), but does not provide meaningful detail for most parameters such as firstNames, lastNames, pastCompany, yearsOfExperienceFilter, or scraperMode. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it searches LinkedIn people with an optional free-text query and advanced filters. This distinguishes it from sibling tools like run_linkedin_company_search and run_linkedin_company_employee, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when searching for LinkedIn people, with support for various filters. It does not explicitly mention alternatives or exclusions, but the scope is unambiguous given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of disclosing behavioral traits. It only states that it 'finds' a profile, without mentioning output format, potential limitations (e.g., profile may not exist), whether it performs a live search, or if any external rate limits apply. This is a significant gap for an agent deciding whether to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Finds') and the key inputs. Every word earns its place, with no redundant padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must also convey what the agent can expect in return. It does not mention the return format (e.g., profile URL, profile details, or null). For a two-parameter lookup, this is a clear but incomplete description; the agent might not know how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because both parameters (full_name and company_or_domain) have inline descriptions. The tool description adds no new meaning beyond what the schema already provides. Per the rubric, with high schema coverage, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find a LinkedIn profile using a company name or domain plus a full name. This is specific and distinguishes it from sibling tools like run_linkedin_people_search (which likely searches by name only) and run_linkedin_company_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you have both a company/domain and a full name. However, it does not explicitly name alternatives or when not to use it, unlike the high-scoring TDQS example. The context is clear but lacks explicit exclusion or alternative guidance.
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?
No annotations are provided, so the description carries the burden of explaining behavior. It discloses the return types, which is useful, but it does not mention whether this is a real-time network check, whether any email is sent, or any side effects or limitations. Basic transparency is present 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and immediately lists the output categories. No redundant or vague wording is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description adequately explains the return values by enumerating deliverability signals, which is essential for the user. It could go slightly deeper (e.g., confidence scale), but for a simple tool it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter 'email' is already well described as 'Email address to validate.' The description adds no extra parameter semantics beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Validates an email address') and lists specific output signals (valid/invalid/risky, catch-all detection, provider, confidence). This verb+resource combination distinguishes it from sibling tools like email finder or enrichment, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an email address needs deliverability checking, but it does not explicitly contrast with alternatives such as run_email_finder or run_email_enrichment. Sibling distinction is left to the tool name and context rather than stated 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?
With no annotations, the description carries the full burden. It accurately indicates a read operation and lists the data fields returned, but it does not disclose any potential errors (e.g., invalid URL), rate limits, or the exact return format, leaving some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word earns its place, with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter fetch tool, the description covers the purpose and lists the expected output fields. Since there is no output schema, the description provides necessary context, though it omits details about error handling and exact return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'url' with a concrete example, achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it fetches structured company data from a Crunchbase company URL. The verb 'Fetches' is specific, and the resource and source are explicitly defined, distinguishing it from sibling tools like run_linkedin_company_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: use this tool when you have a Crunchbase company URL and need company data. It does not explicitly mention alternatives or exclusions, but given the narrow scope, the guidance is adequate.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool is synchronous ('returns the result immediately') and that it performs a read-like operation, but it does not mention rate limits, timeout behavior, or error handling. While it is not destructive, a little more context on runtime constraints would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads the core purpose, and includes a relevant behavioral note about being synchronous. There is zero filler, and every word contributes to the understanding of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately indicates that the result will be extracted structured data, but it does not specify the exact response structure. For a relatively straightforward extraction tool, this is sufficient; however, a detail about the response format would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, with descriptions for all three parameters. The description adds a helpful synthesis by explaining that instructions and/or a JSON schema guide extraction, but it does not add new details about parameter formats or edge cases. The baseline of 3 is appropriate because the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as one that loads a webpage and extracts structured data, using specific verbs ('loads', 'extracts') and resources ('URL', 'structured data'). It is distinct from sibling tools like run_search or run_research, which focus on other operations, so there is no confusion about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever structured data extraction from a webpage is needed, with input via natural-language instructions and/or a JSON schema. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select this tool for extraction tasks.
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?
With no annotations, the description carries the burden of disclosure. It honestly notes that email is returned only 'when available', which is a useful caveat, but it does not address failure modes, rate limits, or whether other contact details are always present. This is minimal but nonzero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the action, input, and output without any redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool without an output schema, the description gives the essential invocation context and a key caveat about email availability. It does not detail the exact response structure or error handling, but the tool's simplicity makes the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a thorough description of the 'username' parameter (full URL with example), giving 100% coverage. The description only reaffirms that the tool uses a full profile URL, adding marginal meaning beyond the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('looks up') and resource ('LinkedIn profile'), with a clear outcome ('returns contact details, including an email address'). It distinguishes itself from sibling search tools by specifying the input must be a full profile URL, making its scope unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the input condition ('by its full profile URL'), which implies when to use this tool versus people or company search. However, it does not explicitly name alternatives or provide exclusion guidance, so it stops short of full comparative instructions.
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?
No annotations are provided, so the description must carry the behavioral burden. It discloses the tool validates and enriches, but does not explicitly state whether it is read-only, what happens on invalid input, or if any rate limits or permissions apply. This is a moderate disclosure level for a likely read-only enrichment tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Validates and enriches' and is entirely free of filler. Every word adds value, and it fits the tool's simple scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity (1 parameter, no output schema), the description is nearly complete. It covers what the tool does and the input requirement. It lacks guidance on when to use this vs. run_phone_enrichment for international numbers, and does not mention error handling, but for a basic enrichment tool this is satisfactory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% - the single parameter 'phone' has a clear description and example. The tool description adds only that it's a US phone number, which is already in the schema, so no extra meaning is provided beyond reinforcing the format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates and enriches a US phone number, listing specific outputs: carrier, line type, activity score, litigator risk, and owner details. It distinguishes from sibling tools like run_phone_enrichment (non-US) and other enrichment tools by focusing on US phone numbers and specific enrichments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'US phone number', giving clear context that this tool is for US numbers. However, it does not explicitly state when NOT to use it or mention alternatives like run_phone_enrichment for non-US numbers. The clear context earns a 4, but absence of exclusions keeps it from a 5.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the operation is asynchronous (returns session_id immediately), that it is multi-step, and that the eventual status can be 'complete' or 'failed'. However, it does not mention potential side effects, prerequisites, or what happens after completion, leaving some transparency gaps for an operation that starts a large workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and includes essential follow-up action (poll get_session_status). Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's async complexity and lack of annotations/output schema, the description covers the essential flow: start the workflow, receive a session_id, and poll until a terminal status. It could mention what the final result looks like or the scope of the workflow, but it is reasonably complete for an entry-point tool, especially since get_session_status is a sibling that likely covers the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the 'instructions' and 'settings' parameters. The description adds no additional parameter-specific meaning; it only restates that instructions are a natural-language task and settings are for the run. This meets the baseline for high schema coverage but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Starts the full NeuralVerge AI research workflow' with a specific verb and resource, and distinguishes it from sibling tools by highlighting the multi-step, full-workflow nature and the immediate return of a session_id. It explicitly mentions polling get_session_status, which clarifies its unique role among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is the entry point for the full research workflow and should be followed by polling get_session_status. It does not explicitly list when to avoid using it or alternatives, but the distinction from more specific search/extract tools is implied. This is clear context without explicit exclusions.
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?
With no annotations, the description carries the full burden. It discloses the synchronous execution and immediate return of structured results, which is valuable. However, it does not address safety (e.g., whether it is read-only), rate limits, authentication requirements, or error behavior, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and return format. It includes only essential details like synchronous execution and no polling, with no redundant or vague wording. It is well-structured and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool, the description covers the main purpose, return structure, and synchronous behavior, while the schema covers parameters. Given the absence of annotations and output schema, it is reasonably complete, though it could briefly explain how settings (like max_results) affect the result set or mention any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the top-level parameters (query and settings both have descriptions), so the baseline is 3. The description does not add any additional meaning to the parameters, and the nested settings properties (country, language, max_results) remain minimally documented, but the high schema coverage makes this acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'runs' and resource 'web search', and specifies the output as a structured list of ranked results (title, url, snippet). This clearly distinguishes it from sibling tools like run_research or run_agent, though it does not explicitly name alternatives. The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating the search is synchronous and returns immediately 'without polling', implying it is suitable for quick, direct search needs. However, it does not explicitly exclude alternatives or mention when to prefer this over run_research or other sibling tools, so it misses the 'when-not' 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 description discloses the asynchronous behavior (returns session_id immediately instead of waiting for completion) and explicitly instructs to poll until 'complete' or 'failed'. This is critical context since no annotations exist. It does not cover side effects like cost or auth, but the core execution model is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences with the primary action and return value in the first and the polling instruction in the second. There is no filler, and it is front-loaded with the key information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description appropriately explains the return value (session_id) and the necessary follow-up polling workflow. It complements the schema by covering the overall lifecycle. It could mention error handling beyond 'failed', but the current guidance is sufficient for the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for all three parameters (agentId, settings, instructions), so the baseline is 3. The tool description adds no extra parameter semantics beyond mentioning agentId in the narrative, which does not enhance the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (runs a saved agent), the resource (a preconfigured NeuralVerge agent identified by agentId), and the immediate result (returns a session_id). It also distinguishes this tool from siblings like run_research or run_search by focusing on running a reusable, preconfigured workflow rather than a specific task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: you use this tool when you have a saved agentId and want to execute it. It also instructs to poll get_session_status afterward, which is a useful follow-up guidance. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a full 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?
With no annotations, the description carries the transparency burden. It discloses the conditional nature of the final result ('once processing completes') and lists the possible statuses, which is valuable. It does not mention side effects, but the verb 'Returns' strongly implies a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no fluff, front-loaded with the core action. Every clause adds useful detail about what is returned and when.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description fully explains the return value (status and result format). It covers the scope of the tool sufficiently and leaves no major gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a fully descriptive comment for session_id (100% coverage), so the description adds no extra parameter information. Baseline 3 is appropriate because the schema does the heavy lifting and the description does not contradict or expand it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns the current status' of a session, enumerating the exact statuses and the final result. It is unmistakably a status-checking tool, distinct from the run_* sibling tools that initiate sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after starting a session (via run_research or run_agent) by referencing those session types, and the schema clarifies the session_id source. However, it does not explicitly state when not to use it or mention alternatives, though none really exist for this 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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/neuralverge/neuralverge-mcp-server'

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