This server acts as an MCP interface for JustSerpAPI, letting you search, explore, and call JustSerpAPI endpoints (Google Search, Google Maps, Google Trends, Web scraping, and more) from any MCP-compatible AI assistant.
search_endpoints: Find the right endpoint using a natural-language query, with optional filtering by service (e.g. google_maps, google_trends, web).
get_endpoint_schema: Inspect the full parameter contract for a specific endpoint, including required/optional parameters and pagination hints.
call_endpoint: Execute any JustSerpAPI endpoint by ID with validated parameters; supports result size limiting and idempotency keys. Returns raw JSON, with large responses automatically truncated.
list_services: See all supported services (e.g. Google Search, Google Maps, Google Trends, Web) along with their endpoint counts.
get_account_balance: Check your subscription and remaining credits.
get_usage_summary: Review recent API usage, consumed credits, and endpoint trends.
refresh_catalog: Re-fetch and update the endpoint catalog from JustSerpAPI's OpenAPI documentation (admin-only).
Provides tools to search Google, access Google Trends, and retrieve Google Shopping results via the JustSerpAPI.
Provides tools to query Google Maps for reviews and other location data.
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., "@justserpapi-mcp Search Google for "best running shoes" in the United States."
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.
Use JustSerpAPI from Codex, Claude Desktop, Cursor, and other MCP-compatible AI assistants.
This MCP server helps your assistant find the right JustSerpAPI endpoint, inspect the required parameters, call the API, and continue paginated results when the API returns a next-page token or offset.
Remote HTTP is the recommended setup.
{
"mcpServers": {
"justserpapi": {
"url": "https://mcp.justserpapi.com/mcp",
"headers": {
"Authorization": "Bearer your_api_key"
}
}
}
}You can also run the MCP server locally with npx.
{
"mcpServers": {
"justserpapi": {
"command": "npx",
"args": ["-y", "justserpapi-mcp"],
"env": {
"JUSTSERPAPI_API_KEY": "your_api_key"
}
}
}
}Related MCP server: SerpApi MCP Server
JustSerpAPI MCP works with MCP-compatible clients that support remote HTTP or local stdio servers, including:
Codex
Claude Desktop
Cursor
Claude Code
OpenAI Agents SDK
Other MCP-compatible AI assistants
Use your JustSerpAPI API key:
Authorization: Bearer your_api_keyFor local stdio, set:
JUSTSERPAPI_API_KEY=your_api_keysearch_endpoints: Find the best JustSerpAPI endpoint from a natural-language request.
get_endpoint_schema: Inspect required parameters, optional parameters, and pagination hints.
call_endpoint: Call a JustSerpAPI endpoint and return raw JSON data.
get_account_balance: Check your subscription and remaining credits.
get_usage_summary: Review recent API usage, consumed credits, and endpoint trends.
list_services: List available services such as Google Search, Google Maps, Google Trends, and Web.
refresh_catalog: Refresh the endpoint catalog from JustSerpAPI docs.
Ask your AI assistant naturally:
Find the Google search API and show me the required parameters.Search Google for "best running shoes" in the United States.Find the Google Maps reviews endpoint and tell me how to request the next page.Get Google Trends trending-now results for the US.Find the Google Shopping search API and call it for "iphone 16 case".Convert this web page to Markdown: https://example.comContinue to the next page of the previous JustSerpAPI result.Check my remaining JustSerpAPI credits.Show my API usage for the last 30 days.The API returned code 402. Explain what it means and what I should check.call_endpoint returns the JustSerpAPI response data as raw JSON. Large arrays
and long text fields may be shortened so the AI assistant can read the result
reliably. When that happens, the response includes truncated: true and the
paths that were shortened.
MIT
Validate params and call a JustSerpAPI endpoint by endpoint_id. Params should use snake_case names from get_endpoint_schema.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_id | Yes | ||
| params | No | ||
| max_items | No | ||
| idempotency_key | No | Optional Idempotency-Key. A random key is generated when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It mentions 'Validate params' but does not disclose error behavior, output format, side effects, permissions, or rate limits. The idempotency_key parameter hints at idempotency but is not explained.
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?
Two sentences, first states purpose, second adds a key usage instruction. No fluff, efficient, and front-loaded with the primary action.
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, 4 parameters, and no output schema, the description is lacking. It omits error handling, return structure, whether the tool is destructive, and authentication requirements. The toolexecutes an external API call and should disclose more behavioral context.
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 only 25% (idempotency_key has a description). The description adds value for the 'params' parameter by specifying naming convention from get_endpoint_schema, but does not elaborate on endpoint_id, max_items, or idempotency_key beyond 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 'Validate params and call a JustSerpAPI endpoint by endpoint_id', specifying the verb (validate and call) and the resource (JustSerpAPI endpoint). This distinguishes it from siblings like get_endpoint_schema (retrieving schema) and search_endpoints (searching).
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 context by stating 'Params should use snake_case names from get_endpoint_schema', suggesting a prerequisite but does not explicitly state when to use the tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full schema and parameter contract for an endpoint_id returned by search_endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_id | Yes | Endpoint id returned by search_endpoints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('Get') and specifies the output as 'full schema and parameter contract'. With no annotations provided, the description adequately conveys the tool's behavior without contradiction.
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, directly stating the tool's purpose without unnecessary words. It is appropriately concise and front-loaded with the key action and resource.
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 tool with one parameter and no output schema, the description fully covers what the tool does, the source of the parameter, and what it returns. No additional details are needed.
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 describes the endpoint_id parameter as 'Endpoint id returned by search_endpoints.' The tool description echoes this information, adding no new semantic meaning beyond the schema. With 100% schema coverage, a score of 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 clearly states the verb 'Get' and the resource 'full schema and parameter contract', and specifies the source of the parameter (from search_endpoints). It distinguishes itself from siblings like call_endpoint, list_services, refresh_catalog, and search_endpoints, which perform different actions.
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 that the endpoint_id must first be obtained via search_endpoints, providing clear context for use. However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported JustSerpAPI services and endpoint counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It only states the action and output type; missing details about authentication, rate limits, caching, or whether the listing is real-time. For a simple read-only tool, this is minimal but not sufficient for full transparency.
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 that is extremely concise and to the point. Every word adds value, with no redundancy or unnecessary elaboration.
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's simplicity (no parameters, no output schema), the description is adequate for a basic listing. However, it could be more complete by hinting at the response format or any prerequisites, which would help the agent make better use of the output.
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?
There are no parameters, so the baseline is 4. The description does not need to add parameter details, and it correctly avoids introducing confusion.
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 specific verb 'list' and the resource 'supported JustSerpAPI services' along with what is included ('endpoint counts'). It effectively distinguishes this tool from siblings like 'call_endpoint' or 'search_endpoints' which serve different purposes.
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 for discovering available services but lacks explicit guidance on when to use this tool versus alternatives like 'search_endpoints' or 'refresh_catalog'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Admin-only. Refresh the endpoint catalog from JustSerpAPI OpenAPI documents.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Reserved for compatibility; refresh still skips writes when unchanged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose all behavioral traits. It mentions 'Admin-only' and 'Refresh', but does not explain effects on existing data, whether the operation is destructive, or the behavior of the 'force' parameter. The schema description partially covers the parameter's behavior, but the tool description lacks sufficient transparency.
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 extremely concise—two short sentences with no filler. It front-loads the critical admin constraint and clearly states the action. Every word serves a 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 no output schema and one parameter, the description is incomplete. It lacks details on return values, side effects, or when the refresh actually writes. Despite simplicity, more context is needed for full clarity.
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 100%, so the schema already documents the single 'force' parameter. The tool description adds no additional parameter info, meeting the baseline for this dimension.
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 'Refresh', the resource 'endpoint catalog', and the source 'JustSerpAPI OpenAPI documents'. It also notes 'Admin-only' as a constraint. This distinguishes it from sibling tools like call_endpoint or search_endpoints, which serve different purposes.
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 you need to refresh the catalog and are an admin, but it does not explicitly state when to use versus alternatives. No guidance on prerequisites or when not to use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find JustSerpAPI endpoint candidates from natural language. Returns endpoint_id candidates; call get_endpoint_schema next.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language endpoint search query. | |
| service | No | Optional service filter, e.g. google_maps, google_trends, web. | |
| platform | No | Deprecated alias for service. | |
| limit | No | ||
| include_deprecated | No | ||
| include_hidden | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states that it returns endpoint_id candidates. It does not disclose behavioral traits such as rate limits, authentication needs, or that it is a read-only query. More detail 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 only two sentences, front-loaded with the main purpose, and contains no filler. Every word adds 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?
Given the tool has 6 parameters and no output schema, the description is minimal but somewhat adequate because the workflow (call get_endpoint_schema next) partly compensates. However, details about return format, pagination, or search behavior are missing.
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 adds no information about parameters beyond what the schema already provides. Although schema coverage is 50%, the tool has 6 parameters and the description does not compensate with any usage hints or format details.
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 'Find' and resource 'JustSerpAPI endpoint candidates', distinguishing from siblings like get_endpoint_schema (mentioned as next step) and call_endpoint. It is specific and actionable.
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 when to use the tool (searching endpoints from natural language) and provides a workflow hint to call get_endpoint_schema next. However, it does not explicitly state when not to use it or compare alternatives like list_services.
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.
v1.0.0call_endpointget_endpoint_schemalist_servicesrefresh_catalogsearch_endpointsEach tool has a clearly distinct purpose: list_services lists available services, search_endpoints finds endpoint candidates, get_endpoint_schema retrieves parameter details for a specific endpoint, call_endpoint executes the API call, and refresh_catalog updates the endpoint catalog. There is no ambiguity or overlap between tools.
All tool names follow a consistent verb_noun pattern using snake_case: list_services, search_endpoints, get_endpoint_schema, call_endpoint, refresh_catalog. The naming style is uniform and predictable.
With 5 tools, the server is lightweight but well-scoped for its purpose of interacting with JustSerpAPI endpoints. It covers the essential workflow of discovering services, searching for endpoints, getting schemas, making calls, and refreshing data. The count feels appropriate, though slightly on the smaller side.
The tool set covers the core lifecycle: discovery (list_services, search_endpoints), parameter retrieval (get_endpoint_schema), execution (call_endpoint), and maintenance (refresh_catalog). There are minor gaps such as missing error handling or status checking tools, but the surface is complete enough for typical usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Web search, news, page retrieval, sitemaps, and trending topics through Search1API.
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
Direct access to 40+ scraping and search tools. Extract structured data from Google (Search, Maps, Trends), Amazon, Airbnb, Social Media, and any web page directly into your AI agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/justserpapi/justserpapi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
