check_domain_against_registryCheck whether a domain or subdomain belongs to a known AI tool - i.e. whether traffic to it is shadow AI. Returns the tool and its risk if matched. Covers the free top 100.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | A domain or URL, e.g. 'chat.openai.com' or 'https://cursor.sh'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral details beyond that: it returns the matched tool and risk, and only if matched. It also discloses coverage ('Covers the free top 100'), which is a meaningful limitation. It does not describe no-match behavior or edge cases, but for a safe read-only tool this is reasonable.
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 two focused sentences. The first states the action and purpose, the second adds return behavior and scope. No filler or redundant content, and it is front-loaded.
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 single-parameter, read-only tool with no output schema, the description covers the key points: what it checks, what it returns when matched, and its coverage limit. Minor gaps include the exact output structure and behavior when no match is found, but these are not critical for tool selection.
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 100% coverage with a clear parameter description and example ('A domain or URL, e.g. "chat.openai.com" or "https://cursor.sh"'). The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
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 whether') and clearly identifies the resource ('domain or subdomain belongs to a known AI tool'). It distinguishes itself from siblings by being domain-oriented rather than listing or top-risk oriented, and adds scope ('Covers the free top 100').
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 clearly implies when to use the tool: when you have a domain/URL and want to determine if traffic to it is shadow AI. It does not explicitly name alternatives or when-not-to-use scenarios, but the context is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a clearly distinct purpose: check_domain_against_registry verifies domains, get_top_risky_ai returns ranked risk, list_shadow_ai provides a filterable list, and lookup_ai_tool_risk retrieves detailed info by name/vendor/domain. No two tools overlap in a way that would cause selection confusion.
All tool names follow a consistent verb_noun pattern using snake_case: check_, get_, list_, lookup_. The verbs accurately describe each action and the pattern is uniform across the set.
With 4 tools, the server is well-scoped for a read-only registry. Each tool covers a distinct query type without being overly redundant or too sparse. This is an appropriate size for the intended purpose.
The server covers the core operations: domain checking, listing, top-risk ranking, and detailed lookup. A minor gap is the lack of a way to discover available categories for filtering, since list_shadow_ai accepts a category parameter but no tool enumerates them. Overall, the surface is nearly complete for a registry lookup service.