Check that a package, module or DOI exists before an agent installs, imports or cites it.
Scored across 4 tools
The tools are mostly distinct: one checks a single identifier, one checks an install command, one checks a manifest, and one watches identifiers over time. There is mild overlap because all four center on the same dependency-verification workflow, but the input type and timing are clearly described.
All tools share the hallux_ prefix and use snake_case, with a mostly verb-object pattern: check, check_command, check_manifest, watch. The inconsistency is minor: 'hallux_check' lacks an explicit object while the other check variants include one, and 'hallux_watch' could more clearly be 'watch_identifiers'.
Four tools is well-scoped for a focused anti-hallucination dependency-checking server. Each tool covers a distinct stage in the workflow without excessive overlap or unnecessary bulk.
The core workflow is covered: individual identifier checks, command preflight checks, manifest batch checks, and long-term monitoring. The only notable gap is the lack of watch management tools (e.g., listing or unregistering watches), but this does not block the primary use case.
Does this identifier actually exist? Call before acting on any name you recalled rather than read: a package to install, a module to import, a DOI to cite.
Returns one of: exists, deprecated, absent, phantom, squat, unknown.
exists - proceed
deprecated - proceed, but use successor
absent - not in the registry. Do not proceed
phantom - does not exist AND models repeatedly invent it. Do not proceed
squat - was invented by models, then registered by someone. Treat as hostile
unknown - could not verify. Never treat this as permission
Live namespaces: cite.doi, pkg.crates, pkg.go, pkg.maven, pkg.npm, pkg.nuget, pkg.pypi. An unsupported namespace returns unknown, never an error, so it is safe to ask.
| Name | Required | Description | Default |
|---|---|---|---|
| identifiers | Yes | Up to 100 identifiers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses the tool's behavior beyond annotations: it explains all six return statuses (exists, deprecated, absent, phantom, squat, unknown) with their meanings, including edge cases like 'squat' and 'phantom'. It also states that unsupported namespaces return 'unknown' rather than an error. This adds significant context beyond the readOnlyHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, a bulleted list of return values, and a closing note on namespaces. It is concise, front-loads the purpose, and every sentence adds value. The use of formatting makes it 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 description is complete for an agent to use correctly: it covers purpose, usage timing, return values, namespaces, and edge cases. There is no output schema, but the description explicitly explains the return format. It leaves no critical gaps for a read-only, idempotent 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?
The schema's description of the 'identifiers' parameter is minimal ('Up to 100 identifiers'), but the tool description adds meaning by listing the supported namespaces and explaining that unsupported ones return 'unknown'. It doesn't detail the format of the 'value' field, but the namespace enum and the behavioral notes compensate. The description adds value beyond the schema, though not exhaustive.
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 with a specific verb and resource: 'Does this identifier actually exist?' It distinguishes itself from siblings (hallux_check_command, hallux_check_manifest) by focusing on identifiers, and provides concrete examples of use cases (package, module, DOI). No tautology.
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 explicit guidance on when to call: 'Call before acting on any name you recalled rather than read' and notes it's safe to ask for any namespace. It doesn't explicitly mention alternatives or exclusions, but the sibling names make the differentiation obvious. The guidance is clear and actionable, though slightly lacking in explicit 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this BEFORE running any command that installs a dependency: npm, yarn, pnpm, bun, pip, uv, poetry, pipx, cargo, go get, dotnet add package, nuget.
Language models invent plausible package names that have never existed, and attackers register those names because they can predict them. Installing one runs attacker code. You cannot tell the difference by looking at the name, which is why this check exists.
Pass the command exactly as you intend to run it. The identifiers are extracted for you.
If the result says BLOCK, do not run the command. Use the successor if one is given, otherwise tell the user what was found and stop.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The shell command, verbatim. Example: pip install requests requests-oauth2-helper |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful context about the typosquatting threat model and the BLOCK/successor result behavior, and it clarifies that identifiers are extracted automatically. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The most important guidance is front-loaded: call before installs, pass the command exactly, and do not run if BLOCK. The threat-model explanation is somewhat non-operational but earns its place by justifying the mandatory nature of the check, and there is no 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?
For a one-parameter, read-only tool, the description covers when to call it, how to pass the command, and how to handle a BLOCK result. It does not explicitly describe the response for a safe command, but the instruction to act only on BLOCK makes the expected behavior inferable.
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 already fully documents the single `command` parameter, so the baseline is 3. The description adds the crucial instruction to pass the command verbatim as it will be run and confirms that identifier extraction is handled by the tool, which removes ambiguity beyond the 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 opens with a precise directive: call this before running any dependency-installing command, and it enumerates the supported package managers. It also explains the security problem it addresses, making the tool's scope unambiguous even without naming sibling 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?
It gives an explicit trigger condition ('before running any command that installs a dependency') and lists concrete package-manager commands. It does not explicitly contrast itself with the sibling tools or state when not to use it, so it falls just short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this after writing or editing a dependency file, and before committing it. Supported: package.json, requirements.txt, pyproject.toml, Cargo.toml, go.mod.
Checks every dependency in one pass, including dev and optional groups, which is where an invented name usually arrives.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The file contents. | |
| filename | Yes | The file name, e.g. package.json. Path is ignored; only the name is used to pick a parser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral context: it checks every dependency, including dev and optional groups, and explains this is where invented names typically show up. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence gives the trigger condition, the second lists supported formats, and the third adds meaningful behavioral detail. Every sentence earns its place.
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 simple two-parameter tool with full schema coverage and read-only/idempotent annotations, the description covers when to call, what it checks, and which files it supports. Nothing essential is missing for correct 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 input schema already documents both parameters fully, so the baseline is 3. The description adds value by enumerating supported file names and clarifying that filename drives parser selection, which helps the agent form valid arguments beyond the schema examples.
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 checks dependencies in a dependency file, lists the supported file types, and gives the specific action ('Checks every dependency in one pass'). It does not explicitly differentiate from sibling tools like hallux_check or hallux_check_command, though the manifest-specific scope is strongly implied.
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 explicit timing guidance: 'Call this after writing or editing a dependency file, and before committing it.' It does not mention alternative tools or exclusions, but the intended use case is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register identifiers for notification when their verdict changes. The transition that matters is phantom to squat: a name models invent that somebody then registers.
Use this for a dependency that came back absent or phantom and that the user intends to use anyway, or for a set of dependencies worth monitoring. Delivered by signed webhook to a URL you supply.
| Name | Required | Description | Default |
|---|---|---|---|
| callbackUrl | Yes | An https URL to POST transitions to. | |
| identifiers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond the annotations: delivery is via a signed webhook to a caller-supplied URL, and the watched transition is specifically phantom to squat. This adds useful operational context without contradicting the readOnlyHint, openWorldHint, idempotentHint, or destructiveHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then gives usage context and delivery details. The phrase 'a name models invent that somebody then registers' is awkward and slightly garbled, but it does not prevent the overall structure from being useful and focused.
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 registration tool with no output schema, the description sufficiently covers what to register, when to register, and how notifications are delivered. It is missing explicit response-handling and duplicate-registration behavior, but the core invocation needs are met.
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 description gives meaning to both parameters: identifiers are dependency names to watch, and callbackUrl is a signed webhook destination supplied by the caller. Since the schema only describes callbackUrl and leaves identifiers undocumented, this description partially compensates, though it does not explain the internal namespace/value structure.
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 a specific verb and resource: 'Register identifiers for notification when their verdict changes.' It also defines the phantom-to-squat transition, clarifying that this is a watch operation rather than a check, which distinguishes it from the sibling check 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 gives clear guidance on when to use the tool: for dependencies that returned absent or phantom but will still be used, or for sets of dependencies worth monitoring. It does not explicitly name alternatives or state when not to use it, but the intended contexts are clear.
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.
hallux_checkhallux_check_commandhallux_check_manifesthallux_watchBlocks typosquatted or hallucinated npm/PyPI packages before an AI agent installs them.
Verify before you act: deps-check, x402-preflight, json-repair & url-read for agents.
Check whether a real-world fact can be verified before an agent acts on it. Free, no auth.
Verify npm packages before your AI agent installs them: hallucinations, advisories, API drift.
Add one secure layer between your agents and this server.