Harrier

by Caleb68864

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: identifiers (username, email, phone, domain), sources (court, genealogy, people-search), and orchestration levels (person_sweep, investigate, build_graph). No two tools have overlapping purposes; even the broader tools are clearly differentiated by their descriptions.
Naming Consistency4/5
The majority of tools follow a target_action pattern (username_sweep, phone_lookup, court_search). A minority use verb_object (generate_candidates, investigate, build_graph), which is a minor deviation but all names are snake_case and readable.
Tool Count5/5
12 tools is well-scoped for an OSINT investigation server, covering identifier-specific lookups, person-specific searches, and higher-level orchestration without being redundant. Each tool earns its place.
Completeness4/5
The surface covers core OSINT workflows: identifier generation, username/email/phone/domain enumeration, court and genealogy searches, plus orchestration and graph building. Minor gaps like reverse image search or IP lookup exist but are not essential to the server's apparent person-centric focus.
Average 3.2/5 across 12 of 12 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 26 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals that the tool is "bounded" and follows a "plan→collect→verify→refine" cycle, but it omits critical behaviors such as whether it requires consent, whether it performs network requests, what side effects occur, and how verification works. The description offers only a high-level workflow without the transparency expected for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short—a single phrase—but this is under-specification rather than conciseness. The arrow notation "plan→collect→verify→refine" is compact but cryptic and does not earn its place for a tool with 13 parameters. Every word is meaningful, yet the content is so minimal that structure adds little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (13 parameters, no output schema, no annotations, and a potential orchestrator role), but the description provides almost no context about inputs, outputs, workflow depth, consent requirements, or relationship to sibling tools. This is severely incomplete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 13 parameters with 0% schema description coverage. The description does not explain any specific parameter—it only hints at "bounded" and "verify" phases, which loosely map to max_rounds and verify but are never explicitly tied to the schema. With no parameter information in either schema or description, this dimension fails to provide meaning beyond the raw field names.
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 chain—"plan→collect→verify→refine"—and identifies the resource as "investigation over all Harrier tools." This distinguishes it from the sibling tools, which appear to be single-purpose utilities. However, it does not explicitly state the outcome (e.g., a report) or the subject (e.g., a person), leaving some ambiguity.
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 phrase "over all Harrier tools" implies this is a broad orchestrator tool to be used when multiple investigation steps are required, rather than a single sibling tool. It does not provide explicit "use when" or "use alternative" guidance, nor does it mention exclusions such as cases where only a quick single lookup is needed.
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, the description carries the full burden of behavioral disclosure. It does mention the authentication requirement, which is helpful, but it omits other critical behavioral traits such as whether the operation is read-only, what the return format is, rate limits, or error behavior. The 'maiden-name resolver' phrase hints at functionality but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. It avoids unnecessary words and includes two additional pieces of information (resolver focus and token requirement) that are not immediately obvious from the schema. However, it may be too brief to fully compensate for missing annotations and schema descriptions.
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 has 4 parameters, no output schema, and no annotations, the description provides insufficient context. It does not explain expected outputs, pagination, error handling, or how the query parameters interact. The description is not complete enough for an agent to fully understand the tool's behavior beyond the basic action.
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 0%, so the description must compensate for explaining parameter meaning. The description's reference to 'maiden-name resolver' partially hints at the maiden parameter, but it does not explain first, last, or married parameters. The parameter names are self-explanatory, but the description adds minimal semantic value beyond the schema property names.
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 clearly states the tool's function as 'Search FamilySearch records', which is a specific verb+resource pairing. The additional qualifier '(maiden-name resolver)' adds nuance about its specialization, though it does not explicitly differentiate from sibling tools like people_search or generate_candidates.
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?
The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions a prerequisite (FAMILYSEARCH_ACCESS_TOKEN) but lacks context for when this tool is preferred over sibling tools that might also perform record searches. No exclusions or alternatives are mentioned.
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?
The description discloses that the tool queries free OSINT sources and returns tier-tagged findings, but with no annotations provided, the description carries the full burden. It lacks detail on important behaviors such as whether it requires consent, how name permutations work, what 'tier-tagged' means, or potential for false positives. The presence of parameters like 'verify' and 'consent' suggests significant behavior that is not disclosed.
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 with no filler words. It front-loads the action and outcome efficiently, earning every word it contains.
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?
For a tool with 13 parameters, no output schema, and no annotations, the description is severely under-specified. It lacks any detail about parameter combinations, result format, or operational expectations, making it insufficient for an agent to correctly invoke the tool in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides zero parameter information. There are 13 parameters, but the description does not even mention that a name is required. The schema itself only has titles (e.g., 'Name', 'Depth', 'Engine') without descriptions, so the agent has no guidance on parameter meaning or usage.
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 ('fan a person out') and resource ('across free OSINT sources'), and clearly states the deliverable ('tier-tagged findings'). This distinguishes it from sibling tools like username_sweep, email_recon, and phone_lookup, which target specific identifiers.
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?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no mention of context, prerequisites, or exclusions. There is no explicit 'when to use' or 'if you need X, use Y' guidance.
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 reveals that PhoneInfoga uses free sources, but it does not mention any side effects, rate limits, data returned, or whether the operation is read-only. This is insufficient for an agent to understand the tool's complete behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that avoids unnecessary words. It is front-loaded with the action and the target. However, it is almost too brief, lacking any structure for additional helpful context, but that is a completeness concern rather than a conciseness flaw.
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 low complexity (two parameters) and no output schema or annotations, the description still does not sufficiently explain what the tool returns, what 'scan' entails, or any caveats. An agent would not know what to expect from the invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for the parameters, and schema coverage is 0%. The description does not explain the meaning of 'selector' (presumably the phone number) or 'timeout'. This leaves the agent without any guidance on how to fill the parameters.
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: scanning a phone number via PhoneInfoga. The verb 'scan' and the resource 'phone number' are specific, and the mention of PhoneInfoga distinguishes this from sibling reconnaissance tools like email_recon or username_sweep.
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 phone number needs to be checked against free OSINT sources. However, it does not explicitly state when to prefer this over sibling tools, nor does it mention exclusions or alternatives.
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 mentions that candidates are 'ranked,' which is a useful trait, but it does not disclose whether the tool makes external calls, how ranking works, what inputs drive ranking, or any side effects. For a generate-only tool, more transparency about output behavior is needed.
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, focused sentence with no filler or repetition. It delivers the core purpose efficiently and is easy to parse.
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?
The tool has six parameters, including optional name parts and an array, and an output schema exists. The description is one sentence and does not explain how parameters like maiden or nicknames affect output, what ranking means, or how the output relates to downstream workflows. Despite having an output schema, the description leaves significant contextual gaps for an agent deciding to invoke this 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 0%, so the description must compensate. It only generically refers to 'name parts,' which vaguely maps to first, last, maiden, married, and nicknames, but it does not explain the role of 'max,' 'maiden,' 'married,' or 'nicknames' in generating candidates. The description adds minimal meaning over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating ranked handle/email candidates from person name parts. It uses a specific verb ('generate') and identifies the resource (handle/email candidates), distinguishing it from sibling tools like username_sweep or email_recon that likely perform checks or recon instead.
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?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusion criteria, or how it relates to sibling tools like username_sweep or email_recon. The context 'from a person's name parts' implies usage but does not say when to choose this over other 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?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: 'makes no network call', which is valuable. However, it does not describe the format of the returned links, how many links are returned, or any limitations or side effects. Some behavioral context is provided but gaps remain.
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 with two clear clauses. Every word contributes to understanding the tool's function and side-effect profile. It is appropriately concise and front-loaded with the primary 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?
For a tool with 5 parameters, no output schema, and no annotations, the description is too sparse. It does not explain what the returned links look like, how many are generated, or how parameters influence the results. Given the tool's apparent role in an investigation workflow, more detail is necessary for an agent to use it correctly.
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 0%, and the description does not mention the parameters (name, city, state, maiden, married) at all. The term 'pre-filled search links' implies parameters are used to populate links, but it does not explain how each parameter maps to the links or what values are expected. The description fails to compensate for the lack of schema documentation.
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 clearly states the tool provides pre-filled search links for walled/gated free sources and explicitly notes it makes no network call. This distinguishes it from sibling tools like people_search or court_search that likely perform automated searches, though it does not name alternatives directly.
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 phrase 'walled/gated free sources' implies this tool is for manual or restricted sources, but it does not explicitly state when to use this tool over siblings or when not to use it. No alternative tools are named, leaving some ambiguity about its role relative to automated search 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and source, without mentioning output format, limitations, filtering options, rate limits, or any side effects. This lack of detail leaves the agent uncertain about what to expect from the invocation.
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 directly states the tool's purpose. There is no unnecessary repetition, filler, or tangential information, making it highly concise and well-structured for quick comprehension.
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 lack of annotations and output schema, the description is the only source of context. It fails to explain the scope of the search (e.g., all federal courts or specific districts), possible result types, or any behaviors like deduplication or paging. The description is too minimal to fully equip an agent for correct invocation and interpretation.
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 0%, so the description must compensate for parameter meanings. The description only implies the 'name' parameter ('by name') and says nothing about the optional 'state' parameter. This is insufficient for a two-parameter tool, especially when the state parameter could be important for narrowing searches.
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 ('Search') and identifies a clear resource ('CourtListener/RECAP federal court records') along with the search target ('a person by name'). This clearly distinguishes it from sibling tools like people_search or person_sweep, which likely cover broader or different record types.
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 the tool (when searching federal court records by name) but does not explicitly state when not to use it or mention alternatives. There is no exclusion or comparison with sibling tools, so the guidance is minimal and inferred.
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 fully disclose behavioral traits. It mentions 'across free OSINT sources,' indicating external lookups, and the verb 'check' suggests a read-only action, but it fails to disclose the return format, failure behavior, or any operational constraints like rate limits or authentication needs. This leaves significant transparency gaps for a recon tool with no other 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 with no filler. It front-loads the key action and scope, ensuring the agent can quickly grasp the tool's purpose. Every word contributes value, making it an exemplary model of conciseness.
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?
The tool has no annotations, no output schema, and an ambiguous parameter. The description covers the high-level purpose but misses critical details such as what 'registered' means in terms of output (e.g., boolean, list of sources) and how to provide the input email (the 'selector' parameter). Given the setup, the description is too sparse for confident tool invocation, making it incomplete for the agent's needs.
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 coverage is 0% and the sole parameter 'selector' is completely undocumented. The description mentions 'email' but does not explicitly state that 'selector' should be the email address, leaving the parameter ambiguous. Since the schema provides no help, the description needed to clarify the mapping between 'selector' and the email address, which it fails to do.
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 ('check') and identifies the resource (whether an email is registered) and the scope (across free OSINT sources). This clearly distinguishes it from sibling tools like username_sweep or phone_lookup, which focus on different identifiers. The title and description align, leaving no ambiguity about the tool's primary function.
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 the tool should be used when you have an email address and need to check its registration status, but it provides no explicit guidance on when to use this over alternatives. There are no stated exclusions or comparisons to sibling tools, making the usage context implied rather than clearly stated.
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 of behavioral disclosure. It does disclose that this is a scrape and that it requires consent, which is a significant behavioral and ethical trait. However, it does not explain what data is returned, whether results are real-time, or whether external site restrictions or rate limits may apply, leaving notable gaps.
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-formed sentence that leads with the core action and packs important contextual information ('free people-search site' and 'consent-gated scrape') into minimal space. There is no redundancy or filler.
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 no annotations, no output schema, and four parameters with no schema descriptions, a single sentence is inadequate. It omits details about the expected return data, the critical default of the consent parameter, and any limitations or behavior when the target site blocks scrapes. A more complete description is necessary for safe and effective use.
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 0%, so the description must compensate. It vaguely suggests the 'name' parameter via 'person' and the 'consent' parameter via 'consent-gated', but it fails to explain the meaning of 'age' and 'city_or_state', and does not warn that consent defaults to false, which would likely cause the scrape to fail. This is insufficient for a 4-parameter tool.
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 ('look up') and resource ('a person on a free people-search site'), and adds a distinctive qualifier ('consent-gated scrape') that separates it from sibling tools like phone_lookup or email_recon. It clearly states what the tool does and its unique scope.
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?
The description gives no explicit guidance on when to use this tool versus alternatives such as person_sweep or genealogy_search. It does not mention exclusions, prerequisites, or preference over other lookup tools. The only implied usage is via 'consent-gated', which hints that consent is a requirement, but this is not developed.
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, the description carries the full burden of behavioral disclosure. It mentions it uses 'Sherlock/Maigret', which implies external network access and a standard enumeration approach, but it fails to explain what the output looks like, whether results are returned to the agent or stored, any rate limiting or timeouts, or whether it is a purely read-only operation. The timeout parameter is not disclosed in the description.
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 with zero wasted words. It immediately states the action and the method ('via Sherlock/Maigret'). It is appropriately concise for a simple tool, though it sacrifices detail for brevity, which is more a completeness issue than a conciseness issue.
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 no annotations and no output schema, the description is incomplete for a tool with network side effects. It does not specify what 'enumerate' returns (e.g., list of found URLs, account names, or just boolean presence), how long it might take, or what happens if the username is not found. The timeout parameter hints at potential delays but is not explained, leaving the agent without enough context to fully understand the operation.
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 coverage is 0%, so the description must compensate. It implies 'a username' likely corresponds to the required 'selector' parameter, but it never explicitly states that selector is the username to search. The 'timeout' parameter is completely undocumented; an agent cannot tell its unit, default, or effect. This is weak compensation for a 2-param schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Enumerate a username across social sites'—a specific verb ('Enumerate') with a specific resource ('a username across social sites'). It distinguishes itself from sibling tools like 'person_sweep' (which likely sweeps a person's name) and 'phone_lookup' (phone numbers).
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 usage is implied: if you have a username and want to check its presence on social sites, use this. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of alternatives, and no exclusions. It doesn't say 'use this if you need to find accounts for a known username' or contrast with 'person_sweep' for full-name searches.
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?
Without annotations, the description must disclose behavioral traits. It adds useful context by stating 'free sources', implying limited scope and potential data coverage limitations. However, it does not mention network dependencies, output format, or potential for long execution times.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the core purpose. It is front-loaded, but its brevity leaves out important details, making it somewhat under-specified for a tool with two parameters.
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?
This is a simple tool with two parameters and no output schema, so the description is the main source of guidance. It fails to explain parameter semantics, usage alternatives, or behavioral caveats, leaving an agent uncertain about how to invoke the tool correctly.
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 0%, so the description must explain parameters. The description implies 'selector' is the domain, but it does not explicitly confirm this or explain the 'timeout' parameter. The only meaningful hint is the phrase 'for a domain', which weakly maps to the required 'selector' field.
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 verb 'harvest' and the resource 'emails/hosts for a domain', and it names the specific tool/method 'theHarvester (free sources)'. This distinguishes it from sibling tools like email_recon by indicating a specific third-party service and scope.
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 this tool is for domain-based email/host harvesting, providing clear context for when it is appropriate. However, it does not explicitly mention alternatives or exclusions, so no comparison to siblings like email_recon is given.
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?
Since no annotations are present, the description carries the burden. It discloses that a person_sweep may be triggered if findings are absent, which is a key side effect, and specifies the return format (graph, GraphML, Cypher exports, summary stats). This goes beyond a simple 'builds a graph' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with a clear purpose, then uses a conditional to explain workflow. The line break and indentation are a bit odd, but the content is efficient and includes necessary technical details.
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 high-level process, the decision branch with findings, and return value, which is useful. However, it omits important context like what 'depth' means, how consent is used, and how it fits with the sibling investigation tools beyond the person_sweep reference. Given the tool's complexity, this is adequate but not complete.
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?
With 11 parameters and zero schema descriptions, the description only clarifies one parameter: findings (as a list of Finding dicts from a prior sweep). It doesn't explain name, depth, consent, nicknames, or the other fields, leaving the agent to guess at their meanings and required formats.
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 opens with 'Build a provenance-stamped entity graph for a person,' clearly stating the tool's action and resource. It differentiates from siblings by explaining how it either uses provided findings or triggers a person_sweep, setting it apart from the other investigation 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 explains the conditional workflow: if findings are supplied, use them; otherwise a verified person_sweep runs first. This gives clear guidance on when to use the tool relative to a prior sweep, though it doesn't explicitly name alternative tools to avoid.
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:

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

Score Badge

Copy to your README.md:

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

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/Caleb68864/Harrier'

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