Check whether a URL or domain is the verified official website of a software product, AI tool, or company. Returns official | not_official (with the real official domains) | insufficient_evidence | unknown. Judges ownership only, never safety.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL or bare domain, e.g. https://claude-desktop.io/download |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the complete output taxonomy, clarifies that not_official comes with the real official domains, and states the scope boundary (ownership only, never safety). It omits process-level details like network behavior or redirect handling, but the essential behavioral traits are covered.
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?
Three sentences with zero waste: purpose, output values, and scope limitation. Each sentence carries distinct information and the primary purpose 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 simple one-parameter classifier with no output schema, the description is nearly complete: it covers purpose, accepted input, all return categories, and what the tool intentionally does not do. The only gap is operational behavior (how verification is performed, failure modes), which is a minor omission for this tool type.
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 100%, so the schema already documents the single url parameter with an example. The description adds marginal context by scoping which kinds of targets are relevant (software products, AI tools, companies) but provides no additional format guidance beyond the schema. Baseline 3 is appropriate.
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 states a specific verb ('check'), a specific resource (URL or domain), and a precise purpose (is it the verified official website). The enumerated return values (official | not_official | insufficient_evidence | unknown) clearly distinguish it from the sibling get_official_url: this tool classifies a given URL rather than retrieving one.
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 core use case is implied by the purpose statement, and 'never safety' is an explicit exclusion that tells the agent not to use this tool for safety judgments. However, the description never names get_official_url or states when to prefer one tool over the other, so alternative routing is left to inference.
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.
The two tools have clearly distinct purposes: one performs a forward lookup by product name, the other does a reverse verification on a provided URL. There is no ambiguity between them.
Both tool names follow the same verb_noun convention with underscores, making the pattern predictable. 'get_official_url' and 'verify_url' are stylistically consistent and readable.
Two tools is on the low end of the typical range, but the domain is narrowly scoped to official URL discovery and verification. Each tool serves a necessary and complementary role, so the count feels reasonable rather than thin.
The tool surface covers both natural operations for this domain: finding the official URL for a name and verifying a given URL. The verify tool also returns evidence-based statuses, so the workflow does not dead-end.