Exports correlated findings into Neo4j Cypher format for entity graph analysis and link visualization.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Harrier sweep username 'johndoe' across platforms"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A disciplined free-source OSINT collection server for LLM agents.
Harrier is a Python / FastMCP server that gives an LLM agent — the /osint Claude Code skill — real, disciplined OSINT collection power over free, public sources. It wraps a fleet of well-known open-source reconnaissance tools behind one normalized contract and returns tier-tagged, confidence-rated, distinctiveness-scored findings instead of a pile of raw tool output. The server collects; it does not judge. Adjudication is left to the analyst and the LLM, and the human is the final gate.
Related MCP server: osint-mcp-server
An LLM is a capable analyst but a poor scraper: it hallucinates URLs, cannot run sherlock, and has no disciplined way to tell a real lead from a coincidence. Point-and-shoot OSINT tools are the inverse — they enumerate aggressively but have no notion of whose account a taken handle is, and they crash the moment a binary is missing or the network hiccups.
Harrier is the connective tissue. It exposes free reconnaissance tooling to an agent through a single stable schema, layers deterministic reasoning on top (correlation, distinctiveness, verification), and refuses to make the probabilistic identity call that belongs to a human. The result is collection an analyst can trust and audit.
Harrier COLLECTS deterministically. The analyst / LLM ADJUDICATES. The human is the final gate.
There is no probabilistic judgment inside the server. Every stage — permutation, correlation, distinctiveness, verification — is deterministic and explainable. The "is this the same person?" call stays outside the tool, with the /osint skill and the operator.
This split drives every other decision:
Principle | What it means in the code |
Public sources only | No logins, no paywalls, no purchased data-broker APIs. Everything wrapped is free and open. |
Consent-gated scraping | The ToS-sensitive people-search scrape tier does nothing unless the caller passes |
No anti-bot / Cloudflare bypass — by design | Harrier never defeats a bot challenge. Where a wall stands, it emits pre-filled manual-assist deep links so the analyst's real browser crosses a wall the tool won't touch. Actively bypassing a challenge strengthens a ToS-circumvention claim; handing a human a link does not. |
FCRA boundary | Findings are read-only context, never a basis for an employment, tenant, insurance, or credit decision. This is stated in the schema, the tools, and here. |
Graceful degradation contract | A missing binary, missing import, bad selector, timeout, or network failure never raises into the sweep. It degrades to an honest |
Harrier is built from small, uniform pieces that compose into one orchestrated sweep.
One module per tool. Every adapter exposes the same shape:
def run(selector, **opts) -> AdapterResult: # a list[Finding] that also carries .status
...AdapterResult subclasses list, so callers iterate it as findings while still reading .status and .reason. The cardinal rule: an adapter degrades, it does not raise.
Finding schemaEvery adapter, from Sherlock to CourtListener, normalizes into one Pydantic model:
Field | Meaning |
| the input that produced this finding (a candidate handle, email, phone, domain) |
| which adapter emitted it ( |
| the hit's URL and resolved value |
| tri-state: |
|
|
| access tier: |
| human-readable note; for blocked findings, the manual step or cause |
|
|
| the untouched adapter payload, for auditing |
Adapters are blocking (subprocess / requests / Playwright), so each job runs in a worker thread via asyncio.to_thread, gated by a semaphore that caps concurrent outbound connections from the host IP. A small random jitter before each job spreads requests out for politeness. One job's failure comes back as the exception object — it never escapes the runner.
Confidence is earned, never assumed. Findings are grouped by a normalized key; a claim confirmed by ≥2 independent source tools is promoted to high, a single-source claim stays low. Intra-tool duplicates are dropped; blocked findings pass through untouched (a manual step is not a confirmed claim).
Username enumeration proves a handle is taken, not whose it is. A hit on abennett is near-zero identity evidence; a hit on amandawademan (an anchor-derived maiden-name handle) is a real lead. Harrier scores that prior in [0,1]: handles embedding a rare, anchor-derived surname score high; common or very short handles score near zero and are suppressed as noise (surfaced only as a count, so nothing vanishes silently). A distinctive existence hit is capped at medium — an unverified lead — never high.
The engine crosses the first name (plus nicknames) over every known surname — last, maiden, and married — because that is the whole point of the maiden-name case: an amanda bennett who was wademan and married into warm should surface amanda.wademan and amandawarm, not just amanda.bennett. Candidates are ranked by real-world handle-shape likelihood, then re-ranked by distinctiveness so rare identity-bearing handles are actually swept rather than truncated behind common shapes.
Enumeration false-positives are the enemy. The verification stage fetches a surfaced profile and scores it against the anchor — deterministically:
dead / 404 / soft-404 page → the enumeration hit was a false positive (exists=False).
page text corroborates a distinctive anchor token (a maiden surname, an uncommon location) as a standalone word → promote confidence.
reachable but no corroboration → left as an unverified lead.
fetch blocked or a JS shell → retry with an optional Playwright render (a real headless browser that executes JS); only if that still can't read it is the finding left unverifiable ("confirm manually").
Word-boundary matching means a handle never self-corroborates: the profile page for amandawademan contains that concatenated handle, but \bwademan\b only matches a standalone "wademan" — a real display name — not the handle echo.
investigate loopinvestigate is a bounded, deterministic plan → collect → verify → refine → synthesize workflow (the "CoAnalyst360 shape"). Each round:
Collect — person_sweep(verify=True) plus a court_search on the current anchor.
Verify — the sweep already fetches, renders, and corroborates; verdicts ride on each finding.
Refine — mine corroborated findings' extracted metadata (e.g. Maigret ids) for a new distinctive surname not already in the anchor. If one appears, fold it in and run another round.
Synthesize — merge and dedup across rounds; assemble next-steps (manual-assist links + unverified / gated leads).
The whole loop is bounded by max_rounds, and refinement only fires when genuinely new metadata surfaces — the engine is honest about finding nothing new and stopping. The agentic reasoning (decomposing the objective, adjudicating matches, writing the narrative) stays in the /osint skill; the deterministic MCP does not make that call.
Harrier registers twelve tools through a one-line-per-tool registration seam in server.py:
Tool | What it does |
| The orchestrator: permute a name → fan out across every adapter under a concurrency cap → correlate → gate by distinctiveness → optionally verify → return tier-tagged findings, a per-source status report, the candidates used, and manual-assist links. |
| The bounded plan→collect→verify→refine→synthesize loop over all Harrier tools. |
| Turn correlated findings into a person-centered entity graph (nodes: accounts / emails / phones / cases / records; edges: provenance-stamped, distinctiveness-weighted) and export it as GraphML and Neo4j Cypher — the "map all connections" link-analysis artifact. |
| Enumerate a username across social sites via Sherlock (primary) with a Maigret fallback. |
| Check whether an email is registered across free sources (holehe + socialscan). |
| Scan a phone number with PhoneInfoga. |
| Harvest emails / hosts / subdomains for a domain via theHarvester. |
| Reach the free people-search layer via a headless browser (consent-gated). |
| Search CourtListener / RECAP federal court records for a person by name. |
| Search FamilySearch records — the free maiden-name resolver. |
| Generate the ranked handle / email-local permutations from a person's name parts. |
| Build pre-filled deep links to walled / gated free sources (genealogy, obituaries, people-search, courts, records) — makes no network call, just constructs URLs. |
Harrier orchestrates these open-source reconnaissance tools and structured sources:
Category | Tools / sources |
Username enumeration | Sherlock, Maigret |
Email recon | holehe, socialscan |
Domain harvesting | theHarvester |
Phone | PhoneInfoga |
Structured, un-walled records | CourtListener / RECAP, FamilySearch |
Two sources accept an optional token for higher limits or record access:
Env var | Effect |
| raises the CourtListener API rate limit |
| enables the FamilySearch record-search API |
Everything degrades honestly without them: no token means an unavailable status with a reason, not an error.
Harrier uses uv and targets Python 3.11+.
# clone, then from the repo root:
uv sync # create the venv and install locked deps
# run the stdio MCP server directly:
uv run harrier-mcpThe wrapped CLI tools (Sherlock, Maigret, theHarvester, PhoneInfoga, …) are optional at runtime — any that are missing simply degrade to unavailable. Install the ones you want on PATH (or as Python deps) to light up those dimensions. For the Playwright render fallback, install browsers once with uv run playwright install chromium.
Register Harrier as a user-scoped MCP server so the /osint skill can call it:
claude mcp add harrier --scope user -- uv run --directory <path-to-harrier-repo> harrier-mcpharrier-mcp is the console entry point declared in pyproject.toml (harrier-mcp = "harrier.server:main"), which starts a FastMCP stdio server.
The /osint skill drives Harrier once it has a confirmed anchor (a real name plus any known city / state / maiden / married surnames). A typical call:
// person_sweep — a single disciplined multi-source sweep
{
"name": "Amanda Bennett",
"state": "NE",
"maiden": "Wademan",
"nicknames": ["Mandy"],
"depth": "deep",
"verify": true,
"consent": false
}…or the full loop:
// investigate — bounded plan→collect→verify→refine→synthesize
{ "name": "Amanda Bennett", "state": "NE", "maiden": "Wademan", "max_rounds": 2 }Every finding comes back tier-tagged and confidence-rated, with a per-source status report and a set of manual-assist deep links for the walls the tool won't cross. Findings are candidates to adjudicate, not facts. The skill and the human decide identity; Harrier only collects the evidence and shows its work.
Harrier is built for legitimate, lawful research — interview prep, B2B due diligence, trust-and-safety triage — over public information only.
Public sources only. No logins, no paywalls, no purchased broker data.
Consent-gated scrape tier. The ToS-sensitive people-search scrape does nothing without explicit consent=True.
No anti-bot bypass. Walls are handed to a human as pre-filled links, never defeated by the tool.
FCRA read-only boundary. Findings are context, never a basis for an employment, tenant, insurance, or credit decision.
You are responsible for using Harrier in compliance with the terms of service of the sources it touches and with applicable law in your jurisdiction.
harrier/
├── pyproject.toml # uv project; harrier-mcp entry point
├── src/harrier/
│ ├── server.py # FastMCP app + one-line-per-tool registration seam
│ ├── schema.py # the normalized Finding contract (Pydantic)
│ ├── candidates.py # name → ranked handle/email permutations
│ ├── distinct.py # handle-distinctiveness scoring
│ ├── correlate.py # cross-source confidence (≥2 tools → high)
│ ├── runner.py # concurrency-capped async fan-out + loop-safe boundary
│ ├── sweep.py # person_sweep orchestrator
│ ├── verify.py # fetch + Playwright-render verification stage
│ ├── investigate.py # bounded plan→collect→verify→refine loop
│ ├── graph.py # build_graph entity graph + GraphML / Cypher export
│ ├── tradecraft.py # ICD-203 likelihood + ICS 206-01 provenance ledger
│ ├── assist.py # manual-assist pre-filled deep-link generator
│ └── adapters/ # one module per tool, uniform run() -> AdapterResult
│ ├── __init__.py # AdapterResult, selector validation, safe subprocess
│ ├── username.py # Sherlock + Maigret
│ ├── email.py # holehe + socialscan
│ ├── phone.py # PhoneInfoga
│ ├── domain.py # theHarvester
│ ├── people_search.py # headless-browser people-search (consent-gated)
│ ├── court.py # CourtListener / RECAP
│ └── genealogy.py # FamilySearch
└── tests/ # 92 tests~92 passing tests covering the schema, every adapter, the runner, correlation, distinctiveness, verification, the sweep, the investigate loop, the tradecraft layer, and the entity graph.
Loop-safe sync ↔ async boundary. FastMCP invokes sync tool bodies while its own event loop is running, which makes a bare asyncio.run and Playwright's sync API raise. run_in_thread / run_coro_sync are the single choke point that offloads to a worker thread only when a loop is actually running — so the server (and the render fallback) behave correctly live, not just in tests.
Selector validation rejects shell metacharacters and path-traversal separators before any selector reaches a subprocess or a temp-file path; subprocesses always run with shell=False and list args.
Bounded, concurrent external calls with a semaphore cap, per-job timeouts, and jitter.
Graceful degradation everywhere — the sweep is contractually incapable of raising.
uv run pytest # 92 passing
uv run pytest -q # quietReleased under the MIT License. See LICENSE for details.
Build a provenance-stamped entity graph for a person.
If ``findings`` (a list of Finding dicts from a prior sweep) is given, the
graph is built from those — no new collection. Otherwise a verified
``person_sweep`` is run first. Returns the graph plus GraphML + Cypher
exports and summary stats.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| name | Yes | ||
| depth | No | quick | |
| No | |||
| phone | No | ||
| state | No | ||
| maiden | No | ||
| consent | No | ||
| married | No | ||
| findings | No | ||
| nicknames | No |
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.
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.
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.
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.
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.
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.
Search CourtListener/RECAP federal court records for a person by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| state | No |
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.
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.
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.
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.
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.
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.
Harvest emails/hosts for a domain via theHarvester (free sources).
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | ||
| selector | Yes |
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.
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.
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.
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.
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.
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.
Check whether an email is registered across free OSINT sources.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes |
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.
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.
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.
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.
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.
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.
Search FamilySearch records (maiden-name resolver; needs FAMILYSEARCH_ACCESS_TOKEN).
| Name | Required | Description | Default |
|---|---|---|---|
| last | Yes | ||
| first | Yes | ||
| maiden | No | ||
| married | No |
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.
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.
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.
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.
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.
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.
Generate ranked handle/email candidates from a person's name parts.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | ||
| last | Yes | ||
| first | Yes | ||
| maiden | No | ||
| married | No | ||
| nicknames | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Bounded plan→collect→verify→refine investigation over all Harrier tools.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| name | Yes | ||
| depth | No | quick | |
| No | |||
| phone | No | ||
| state | No | ||
| engine | No | sherlock | |
| maiden | No | ||
| verify | No | ||
| consent | No | ||
| married | No | ||
| nicknames | No | ||
| max_rounds | No |
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.
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.
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.
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.
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.
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.
Pre-filled search links for walled/gated free sources (makes no network call).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| name | Yes | ||
| state | No | ||
| maiden | No | ||
| married | No |
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.
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.
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.
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.
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.
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.
Look up a person on a free people-search site (consent-gated scrape).
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | ||
| name | Yes | ||
| consent | No | ||
| city_or_state | No |
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.
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.
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.
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.
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.
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.
Fan a person out across free OSINT sources; return tier-tagged findings.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| name | Yes | ||
| depth | No | quick | |
| No | |||
| phone | No | ||
| state | No | ||
| engine | No | sherlock | |
| maiden | No | ||
| verify | No | ||
| consent | No | ||
| married | No | ||
| permute | No | ||
| nicknames | No |
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.
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.
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.
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.
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.
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.
Scan a phone number with PhoneInfoga (free sources).
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | ||
| selector | Yes |
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.
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.
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.
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.
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.
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.
Enumerate a username across social sites via Sherlock/Maigret.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | ||
| selector | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0build_graphcourt_searchdomain_harvestemail_recongenealogy_searchgenerate_candidatesinvestigatemanual_assistpeople_searchperson_sweepphone_lookupusername_sweepEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic web intake and data utilities for autonomous agents.
Sovereign Agent OS — Persistent Memory, Governance & Compliance for AI Agents.
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
