MCP server for AI agents to search local businesses worldwide via the Discava API.
Add to your Claude Desktop config (~/.claude/claude_desktop_config.json):
{
"mcpServers": {
"discava": {
"command": "npx",
"args": ["tsx", "/path/to/discava/mcp/server.ts"]
}
}
}claude mcp add discava npx tsx /path/to/discava/mcp/server.tsRelated MCP server: AI List My Business
Tool | Description |
| Search for businesses by query, city, country |
| Get full details for a business by ID |
| Report data quality issues |
| Top businesses by demand score |
| Autocomplete for cities and categories |
Variable | Default | Description |
|
| API base URL |
Get full details for one or more businesses: address, phone, website, opening hours, services, payment methods, social links, logo, business image, coordinates. Pass comma-separated IDs for batch.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | One or more business IDs, comma-separated for batch (e.g. "id1,id2,id3") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the batch capability and the type of details returned, but lacks information on permissions, rate limits, error handling, or whether it's a read-only operation (though 'Get' implies read). This leaves gaps for a tool with no annotation coverage.
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 sentences: the first front-loaded with the purpose and key details, the second specifying the parameter usage. Every sentence adds value with no wasted words, making it efficient and well-structured.
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 and no output schema, the description covers the basic purpose and batch usage but lacks details on return format, error cases, or behavioral traits like rate limits. For a tool with 1 parameter and high schema coverage, it's minimally adequate but could be more complete to compensate for missing structured data.
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 'id' parameter as comma-separated IDs for batch. The description adds minimal value by restating this in natural language ('Pass comma-separated IDs for batch'), but doesn't provide additional semantics like ID format or constraints 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 clearly states the verb ('Get') and resource ('full details for one or more businesses'), and lists specific data fields (address, phone, website, etc.) that distinguish it from siblings like search_businesses (likely for searching) or get_rankings (likely for rankings). It explicitly handles batch operations with comma-separated IDs.
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 provides clear context for when to use it ('for one or more businesses' and 'batch'), implying it's for retrieving details of known IDs rather than searching. However, it doesn't explicitly state when not to use it or name alternatives like search_businesses for unknown businesses, though the distinction is reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top businesses by demand score.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ISO country code (required) | |
| category | No | Category slug or name | |
| city | No | City name | |
| limit | No | Results (1-20) | |
| lang | No | Language for labels | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't mention whether it's read-only, has rate limits, authentication requirements, or what the output format looks like. For a tool with 5 parameters and no output schema, this is inadequate.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple retrieval tool and gets straight to the point without 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?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'demand score' means, what the output format looks like, or provide any behavioral context. The agent would need to guess about important aspects of tool behavior.
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 all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, which meets the baseline expectation when schema coverage is high.
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 action ('Get') and resource ('top businesses by demand score'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'search_businesses' or 'get_business', which likely retrieve business data in different ways.
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 provides no guidance on when to use this tool versus alternatives like 'search_businesses' or 'get_business'. It lacks context about when this ranking-focused tool is appropriate compared to other business retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the discava API is online.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool does but doesn't disclose behavioral traits like response format, error conditions, authentication requirements, rate limits, or whether it's idempotent. For a health check tool with zero annotation coverage, this is a significant gap.
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, efficient sentence with zero waste. It's appropriately sized for a simple health check tool and front-loads the essential information. Every word 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?
Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is incomplete. It doesn't explain what 'online' means operationally, what the return value indicates, or potential failure modes. For a health check that agents might rely on for system status, more context would be helpful.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the empty input. The description doesn't need to add parameter information, and the baseline for 0 parameters is 4. No additional parameter semantics are required or provided.
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: 'Check if the discava API is online.' It uses a specific verb ('Check') and identifies the resource ('discava API'), but doesn't differentiate from sibling tools like 'get_business' or 'search_businesses' 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or suggest when this health check should be performed relative to other operations. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for local businesses. Returns name, category, city, country, logo_url, available_details (what data exists), and scores. Check available_details to see what is available, then call get_business for full details.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query (e.g. "plumber", "Zahnarzt", "Italian restaurant") | |
| city | No | City name (e.g. "Hamburg", "Wien", "New York") | |
| country | Yes | ISO country code (e.g. "DE", "AT", "CH", "US"). Required. | |
| category | No | Category slug (e.g. "plumber", "restaurant", "dentist") | |
| limit | No | Number of results (1-50, default 10) | |
| page | No | Page number | |
| min_confidence | No | Min confidence score 0-100 | |
| lang | No | Language for labels: "de" or "en" | en |
| lat | No | Latitude for distance | |
| lon | No | Longitude for distance |
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 describes the return structure and the workflow with get_business, which adds value. However, it doesn't mention rate limits, authentication requirements, pagination behavior beyond the page parameter, error conditions, or whether this is a read-only operation. For a search tool with 10 parameters and no annotations, more behavioral context would be helpful.
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 and well-structured in just two sentences. The first sentence states the purpose and return fields, while the second provides crucial workflow guidance. Every word earns its place with zero wasted text, making it front-loaded and efficient.
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 complexity (10 parameters, no annotations, no output schema), the description does a good job of explaining the core purpose and workflow. It clarifies the relationship with get_business, which is important context. However, for a search tool with many parameters and no output schema, more information about result format, pagination behavior, or error handling would make it more complete.
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 all 10 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 specific verb ('Search') and resource ('local businesses'), and distinguishes it from sibling get_business by explaining the relationship between search results and detailed data retrieval. It explicitly mentions the return fields (name, category, city, etc.), making the purpose highly specific and differentiated.
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 provides explicit guidance on when to use this tool versus alternatives: 'Check available_details to see what is available, then call get_business for full details.' This clearly establishes the workflow relationship with the sibling get_business tool, indicating this is for initial search and the other for detailed retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report data quality issues for a business.
| Name | Required | Description | Default |
|---|---|---|---|
| business_id | Yes | Business ID | |
| type | Yes | Feedback type | |
| comment | No | Description of the issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a write operation ('Report'), but doesn't specify whether this is a mutation, if it requires authentication, what happens after submission (e.g., confirmation, error handling), or any rate limits. For a tool that likely modifies data, this is a significant gap in 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, efficient sentence: 'Report data quality issues for a business.' It is front-loaded with the core purpose and wastes no words, making it highly concise and well-structured.
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 complexity (a mutation tool for reporting issues), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, response format, or error conditions. For a tool that likely impacts data quality, more context is needed to guide the agent effectively.
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 all parameters (business_id, type, comment) with descriptions and enum values for 'type.' The description adds no additional meaning beyond the schema, such as explaining the business_id format or when to use each feedback type. Baseline 3 is appropriate as the schema does the heavy lifting.
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: 'Report data quality issues for a business.' It specifies the verb 'Report' and the resource 'data quality issues for a business,' making it distinct from siblings like get_business or search_businesses. However, it doesn't explicitly differentiate from all siblings (e.g., suggest might be related), so it falls short of a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a business ID), exclusions, or comparisons to siblings like get_business (which might retrieve data) or suggest (which might propose changes). This lack of context leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Autocomplete for cities or categories/business names.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text (min 2 chars) | |
| type | No | "city" or "query" | query |
| country | No | ISO country code to filter | |
| limit | No | Max suggestions |
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 states the tool is for autocomplete but doesn't cover aspects like rate limits, authentication needs, error handling, or response format. This leaves significant gaps for a tool with 4 parameters and no output schema.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration, making it easy to parse quickly.
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 complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, output format, and usage context, which are crucial for an autocomplete tool that likely returns structured suggestions. The high schema coverage doesn't compensate for these gaps.
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 all parameters thoroughly. The description adds minimal value by hinting at the 'type' parameter's purpose (city vs. query), but it doesn't provide additional syntax or format details beyond what the schema offers, meeting the baseline for high coverage.
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 as 'Autocomplete for cities or categories/business names,' which specifies the verb (autocomplete) and resources (cities, categories/business names). It distinguishes from siblings like get_business or search_businesses by focusing on suggestions rather than retrieval or search, though it doesn't explicitly name alternatives.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer suggest over search_businesses or get_business, nor does it specify prerequisites or exclusions, leaving usage context implied at best.
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.0get_businessget_rankingshealth_checksearch_businessessend_feedbacksuggestEach tool has a clearly distinct purpose with no overlap: get_business retrieves detailed business data, get_rankings provides demand-based rankings, health_check checks API status, search_businesses finds businesses with basic info, send_feedback reports issues, and suggest handles autocomplete. The descriptions clearly differentiate their functions, eliminating any ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., get_business, get_rankings, search_businesses, send_feedback, health_check, suggest), with verbs like 'get', 'search', 'send', and 'suggest' applied appropriately. There are no deviations in naming conventions, making the set predictable and readable.
With 6 tools, the count is well-scoped for a business directory server, covering core operations like retrieval, search, rankings, feedback, autocomplete, and health checks. Each tool earns its place without feeling excessive or insufficient for the domain's needs.
The tool surface is largely complete for a business directory, covering key workflows: search, detailed retrieval, rankings, feedback, and autocomplete. A minor gap exists in update or creation tools for business data, but this is reasonable for a directory focused on querying and reporting, and agents can work around this with the provided tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live Google Maps business search, review, and photo data for AI agents over MCP.
Search real businesses, then read profiles, services and hours or contact them, in one endpoint.
Local business intel for AI agents: audits, lead scoring, tech stack, prospecting.
Search a directory of real, owner-confirmed small businesses. Read-only; attribution required.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/discava/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
