Skip to main content
Glama

url_is_alive

Verify if a URL is accessible by checking its status using the ReviewWebsite API. Input the URL, set a timeout, and optionally use a proxy to confirm availability.

Instructions

Check if a URL is alive using ReviewWeb.site API.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
api_keyNoYour ReviewWebsite API key
proxyUrlNoProxy URL to use for the request
timeoutNoRequest timeout in milliseconds (default: 10000)
urlYesURL to check if it's alive

Implementation Reference

  • The MCP tool handler function `handleIsUrlAlive` that processes tool arguments, calls the controller, and formats the response for MCP.
    async function handleIsUrlAlive(args: UrlIsAliveToolArgsType) {
    	const methodLogger = Logger.forContext(
    		'tools/reviewwebsite.tool.ts',
    		'handleIsUrlAlive',
    	);
    	methodLogger.debug(`Checking if URL is alive with options:`, {
    		...args,
    		api_key: args.api_key ? '[REDACTED]' : undefined,
    	});
    
    	try {
    		const result = await reviewWebsiteController.isUrlAlive(
    			args.url,
    			{
    				timeout: args.timeout,
    				proxyUrl: args.proxyUrl,
    			},
    			{
    				api_key: args.api_key,
    			},
    		);
    
    		return {
    			content: [
    				{
    					type: 'text' as const,
    					text: result.content,
    				},
    			],
    		};
    	} catch (error) {
    		methodLogger.error(`Error checking if URL is alive`, error);
    		return formatErrorForMcpTool(error);
    	}
    }
  • Zod schema defining the input arguments for the `url_is_alive` tool.
    export const UrlIsAliveToolArgs = z.object({
    	url: z.string().describe("URL to check if it's alive"),
    	timeout: z
    		.number()
    		.optional()
    		.describe('Request timeout in milliseconds (default: 10000)'),
    	proxyUrl: z
    		.string()
    		.optional()
    		.describe('Proxy URL to use for the request'),
    	api_key: z.string().optional().describe('Your ReviewWebsite API key'),
    });
  • Registration of the `url_is_alive` MCP tool, specifying name, description, input schema, and handler function.
    	'url_is_alive',
    	`Check if a URL is alive using ReviewWeb.site API.`,
    	UrlIsAliveToolArgs.shape,
    	handleIsUrlAlive,
    );
  • Service-level implementation that performs the actual HTTP GET request to the ReviewWeb.site API `/url/is-alive` endpoint to check if the URL is alive.
    async function isUrlAlive(
    	url: string,
    	options?: UrlIsAliveOptions,
    	apiKey?: string,
    ): Promise<any> {
    	const methodLogger = Logger.forContext(
    		'services/vendor.reviewwebsite.service.ts',
    		'isUrlAlive',
    	);
    
    	try {
    		methodLogger.debug('Checking if URL is alive', { url, options });
    
    		// Build query parameters
    		const params = new URLSearchParams();
    		params.append('url', url);
    
    		if (options?.timeout) {
    			params.append('timeout', options.timeout.toString());
    		}
    
    		if (options?.proxyUrl) {
    			params.append('proxyUrl', options.proxyUrl);
    		}
    
    		const response = await axios.get(`${API_BASE}/url/is-alive`, {
    			params,
    			headers: getHeaders(apiKey),
    		});
    
    		methodLogger.debug('Successfully checked if URL is alive');
    		return response.data;
    	} catch (error) {
    		return handleApiError(error, 'isUrlAlive');
    	}
    }
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 the API ('ReviewWeb.site API') but doesn't describe key traits like what 'alive' means (e.g., HTTP status codes, response time thresholds), error handling, rate limits, or authentication needs beyond the 'api_key' parameter. This leaves significant gaps in understanding the tool's behavior and constraints.

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, efficient sentence that front-loads the core purpose without unnecessary details. It uses minimal words to convey the essential action and method, making it easy to parse and understand quickly. There's no wasted verbiage, and it's structured for immediate 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 complexity of a URL-checking tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'alive' entails (e.g., success criteria, return format), how errors are handled, or dependencies like the API's behavior. For a tool that interacts with external services and has multiple parameters, more context is needed to ensure reliable use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no parameter-specific information beyond what's in the input schema, which has 100% coverage with clear descriptions for all 4 parameters. Since the schema fully documents parameters like 'url' and 'timeout', the baseline score of 3 is appropriate—the description doesn't compensate but also doesn't detract, as the schema handles the semantics adequately.

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 purpose: 'Check if a URL is alive using ReviewWeb.site API.' It specifies the action ('Check'), resource ('URL'), and method ('using ReviewWeb.site API'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'url_get_after_redirects' or 'scrape_url', which might also involve URL checking but with different scopes.

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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or specify contexts like checking URL availability versus scraping content, leaving the agent to infer usage based on the tool name alone. This lack of explicit when-to-use or when-not-to-use instructions limits its effectiveness in tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Related Tools

Latest Blog Posts

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/mrgoonie/reviewwebsite-mcp-server'

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