The infobel-api-mcp server provides access to the Infobel worldwide business database, enabling business data search, retrieval, and exploration.
Search & Retrieve Businesses
Search millions of businesses using filters like name, location (country, city, region, postal code, coordinates), category, contact info (phone, email, website), employee count, sales volume, corporate hierarchy, and presence indicators (has email, has LinkedIn, etc.)
Paginate through search results using a searchId, or check the status of a previous search
Retrieve full or partial business records by unique ID and country code
Category Discovery
Search Infobel proprietary, ISIC (international), NACE (European), and local/national category codes (e.g., SIC, NAF) by keyword
Location Discovery
List available countries, regions, and provinces; search cities by keyword; or search locations (cities, regions, provinces) by multiple keywords at once
Reference / Lookup Data
Retrieve lists of supported languages, reliability codes, business status codes, geographic precision levels, currencies, sorting options, website status flags, social media platforms, import/export agent codes, legal status codes, national ID types, technographic tags, and executive tags
Connectivity
Test API connectivity and authentication
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., "@infobel-api-mcp search for bakeries in London, UK"
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.
Python client and MCP server for the Infobel GetData API.
From PyPI:
pip install infobel-api-mcpFor local development:
pip install -e .Requires Python 3.10+.
Related MCP server: filed-mcp-server
After installing, run one command to wire infobel-mcp into your agent host:
# User-global config (prompts for credentials)
infobel-mcp add claude # writes ~/.claude.json
infobel-mcp add codex # writes ~/.codex/config.toml
infobel-mcp add gemini # writes ~/.gemini/settings.json (uses env var placeholders)
# Project-local config (cwd)
infobel-mcp add claude --local
infobel-mcp add codex --local
infobel-mcp add gemini --local
# Project-local config at a specific path
infobel-mcp add claude --local /path/to/project
# Skip the interactive prompts
infobel-mcp add claude --username myuser --password mypass
# Write ${INFOBEL_USERNAME}/${INFOBEL_PASSWORD} placeholders instead of literal creds
infobel-mcp add claude --use-env-varsAfter running the command, set your credentials as environment variables:
export INFOBEL_USERNAME="your-username"
export INFOBEL_PASSWORD="your-password"Set your credentials as environment variables:
export INFOBEL_USERNAME="your-username"
export INFOBEL_PASSWORD="your-password"Or pass them directly when creating a client:
from infobel_api import InfobelClient
client = InfobelClient(username="your-username", password="your-password")from infobel_api import InfobelClient
with InfobelClient() as client:
result = client.search.search(country_codes="GB", business_name="Acme")
print(result["counts"]["total"]) # total matching businesses
print(result["firstPageRecords"]) # [] by defaultreturn_first_page defaults to False, so search() returns counts and a searchId without embedding records unless you explicitly opt in.
with InfobelClient() as client:
# Start a search
result = client.search.search(
country_codes="US",
business_name="Tesla",
)
search_id = result["searchId"]
# Fetch page 1 with only the fields you need
page = client.search.post_records(
search_id,
page=1,
fields=["uniqueID", "businessName", "phone", "email", "city"],
)
for record in page["records"]:
print(record)
# Fetch page 2
page2 = client.search.post_records(search_id, page=2, fields=["uniqueID", "businessName"])with InfobelClient() as client:
record = client.record.get(country_code="US", unique_id="0226550061")
print(record["businessName"], record["phone"])with InfobelClient() as client:
# By national ID
result = client.search.search(country_codes="BE", national_id="0123456789")
# Businesses with email in a city
result = client.search.search(
country_codes="FR",
city_names="Paris",
has_email=True,
)
# Filter by employee count
result = client.search.search(
country_codes="DE",
employees_total_from=50,
employees_total_to=200,
)The package ships an MCP server that exposes the Infobel API as tools for AI agents (Claude, etc.).
After installing the package, register the MCP server with:
infobel-mcp add claudeThis automatically uses the Python executable that has the package installed, regardless of whether you are in a venv, conda environment, or using the system Python.
As of March 18, 2026, Claude Code stores MCP servers in:
User scope: ~/.claude.json
Project scope: /path/to/project/.mcp.json
On Windows, ~/.claude.json maps to your home directory, typically %USERPROFILE%\\.claude.json.
Add this to either file:
{
"mcpServers": {
"infobel": {
"type": "stdio",
"command": "/path/to/your/python",
"args": ["-m", "infobel_api.mcp_server"],
"env": {
"INFOBEL_USERNAME": "your-username",
"INFOBEL_PASSWORD": "your-password"
}
}
}
}Replace /path/to/your/python with the Python executable that has infobel-api-mcp installed. To find it, run this inside the environment where the package is installed:
python -c "import sys; print(sys.executable)"For a venv the path typically looks like /path/to/project/venv/bin/python. For conda it looks like /opt/conda/envs/myenv/bin/python. The infobel-mcp add claude command above handles this automatically.
Gemini CLI stores MCP servers in:
User scope: ~/.gemini/settings.json
Project scope: /path/to/project/.gemini/settings.json
On Windows, ~/.gemini/settings.json maps to your home directory, typically %USERPROFILE%\\.gemini\\settings.json.
Add this to the settings.json file:
{
"mcpServers": {
"infobel": {
"command": "/path/to/your/python",
"args": ["-m", "infobel_api.mcp_server"],
"env": {
"INFOBEL_USERNAME": "${INFOBEL_USERNAME}",
"INFOBEL_PASSWORD": "${INFOBEL_PASSWORD}"
}
}
}
}Replace /path/to/your/python with the Python executable that has infobel-api-mcp installed (see the note in the Claude Code section above). If your settings.json already contains other top-level keys, merge the mcpServers block into the existing file instead of replacing it.
Codex stores MCP servers in:
User scope: ~/.codex/config.toml
Project scope: /path/to/project/.codex/config.toml
On Windows, ~/.codex/config.toml maps to your home directory, typically %USERPROFILE%\\.codex\\config.toml.
Add this to config.toml:
[mcp_servers.infobel]
command = "/path/to/your/python"
args = ["-m", "infobel_api.mcp_server"]
[mcp_servers.infobel.env]
INFOBEL_USERNAME = "your-username"
INFOBEL_PASSWORD = "your-password"Replace /path/to/your/python with the Python executable that has infobel-api-mcp installed (see the note in the Claude Code section above). Codex CLI and the Codex IDE extension share the same MCP configuration.
Claude Desktop is a separate app from Claude Code and uses a different config. The easiest path for end users is the bundled Desktop Extension (.mcpb): no Python install, no manual JSON, no PATH setup. The user double-clicks the bundle, Claude Desktop prompts for the Infobel username and password, and the tools appear.
Install (for users):
Download infobel-getdata.mcpb from the releases page.
Double-click it (or in Claude Desktop: Settings → Extensions → Install Extension…).
Enter your Infobel username and password in the dialog. The password is stored securely in the OS keychain.
Fully quit and reopen Claude Desktop. The Infobel tools are now available.
The bundle uses the MCPB uv server type — Claude Desktop runs uv to resolve dependencies cross-platform at install time, so users do not need their own Python.
Build the bundle (for maintainers):
./build_mcpb.sh # → dist/infobel-getdata.mcpbRequires Node.js (the script invokes npx @anthropic-ai/mcpb). The manifest lives in mcpb/manifest.json; bump its version on each release. Attach the resulting .mcpb to a GitHub Release.
Configure Claude Desktop manually (alternative to the extension): edit the config file directly —
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\\Claude\\claude_desktop_config.json
{
"mcpServers": {
"infobel": {
"command": "/path/to/your/python",
"args": ["-m", "infobel_api.mcp_server"],
"env": {
"INFOBEL_USERNAME": "your-username",
"INFOBEL_PASSWORD": "your-password"
}
}
}
}Claude Desktop does not inherit your shell environment or expand ${VAR} placeholders, so the command must be an absolute Python path and credentials must be literal values. Fully restart the app after editing.
Tool | Description |
| Search by name, location, category, and more |
| Fetch additional pages from a previous search |
| Get a full business record by unique ID |
| Get a lightweight record by unique ID |
| Browse Infobel category tree |
| Browse ISIC categories |
| Browse local/national categories |
| List cities for a country |
| List regions for a country |
| List provinces for a country |
| List all available countries |
| List available display languages |
| Verify API connectivity |
Once configured, you can ask Claude things like:
"Find all Italian restaurants in Brussels with a phone number."
Claude will call search_businesses with the right filters and return structured results. You tell it which fields you care about:
"Search for Google offices in the US — I only need the business name, address, and phone number."
The record_fields parameter controls what comes back (pass [] for counts only):
search_businesses(
country_codes=["US"],
business_name=["Google"],
record_fields=["businessName", "address1", "city", "phone"]
)To get more pages, use the searchId from the first call:
get_search_results(
search_id=12345,
page=2,
record_fields=["businessName", "address1", "city", "phone"]
)from infobel_api import InfobelAPIError, AuthenticationError, RateLimitError, NetworkError
try:
result = client.search.search(country_codes="GB", business_name="Acme")
except AuthenticationError:
print("Invalid credentials")
except RateLimitError:
print("Rate limited — retries are automatic")
except NetworkError:
print("Connection issue")
except InfobelAPIError as e:
print(f"API error {e.status_code}: {e.message}")The client handles rate limiting and retries automatically.
List all countries available in the Infobel database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description is minimal and does not disclose caching, authentication, or response behavior. However, the tool is simple and read-only.
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?
Single sentence with no unnecessary words. 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 zero parameters and existence of output schema, the description provides sufficient context for a simple listing tool.
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?
No parameters; description adds context ('countries in Infobel database') beyond the empty schema. Baseline for zero parameters is 4.
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?
Description clearly states 'List all countries available in the Infobel database.' with a specific verb and resource, distinguishing it from siblings like get_cities or get_provinces.
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?
No guidance on when to use this tool versus alternatives. While the purpose is clear, it lacks explicit when-not or conditional usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cities within a country by keyword.
Use the returned codes as city_codes in search_businesses filters. Always provide a specific city name or partial name — never call without a keyword.
Args: country_code: ISO 3166-1 alpha-2 country code (e.g. "US", "GB"). keyword: City name or partial name to search for (e.g. "New York", "Munich"). province_code: Optional province code to narrow results to a specific province/state. language_code: Display language for results (e.g. "en", "de", "fr").
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | ||
| keyword | Yes | ||
| province_code | No | ||
| language_code | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions returning codes but does not specify result limits, pagination, error handling, or whether the operation is read-only. For a search tool with no annotations, this is insufficient.
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 compact, front-loaded with purpose, then usage guidance, then parameter list. No unnecessary sentences, and every line 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?
The description covers purpose, parameter usage, and downstream integration with search_businesses. An output schema exists, so return values need not be detailed. For a simple search tool, this is largely complete, though lacking behavioral details.
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 0%, so the description must compensate. It explains each parameter (e.g., country_code is ISO 3166-1 alpha-2, keyword is city name or partial name), which adds meaning beyond the parameter names. However, the explanations are brief and do not cover all nuances like format or constraints.
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 'Search cities within a country by keyword' and specifies the use of returned codes in search_businesses filters. This verb+resource+scope distinguishes it from sibling tools like get_provinces or get_locations.
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?
Explicitly advises to always provide a keyword and never call without one, and explains how to use the results. However, it does not explicitly contrast with sibling tools or cover when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported currencies for the sales_volume_currency search filter.
Returns currency codes such as Local (0), USD (1), EUR (2).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is adequate for a simple read-only list tool, disclosing that it returns currency codes with examples. It lacks details on authentication, rate limits, or side effects, but these are not critical for this tool.
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 with two sentences, no unnecessary words, and the key information 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?
Given the simplicity (zero parameters, read-only, output schema exists), the description provides all necessary context: what the tool does, for which filter, and what the output looks like.
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 no parameters, so baseline is 4. The description adds value by explaining the purpose and sample output, though it does not need to describe parameter semantics.
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 lists supported currencies for a specific search filter, with examples of return values. It effectively distinguishes from sibling tools like get_countries or get_cities by specifying the currency context.
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?
It explicitly ties the tool to the `sales_volume_currency` search filter, providing clear context for when to use it. However, it does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List executive tags for the executive_tags search filter.
Executive tags describe attributes or roles of business executives.
Args: keyword: Optional keyword to filter results (e.g. "ceo", "founder").
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'List' (a read operation) but omits details like authentication requirements, pagination, or potential rate limits. The output schema exists but is not referenced or summarized.
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 concise and well-structured: a one-sentence purpose, a brief definition, and a simple parameter list. Every sentence adds value without redundancy.
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 (one optional parameter, output schema present), the description is nearly complete. It covers purpose and parameter meaning, but could mention the return type or that tags are used for filtering search results.
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?
Despite 0% schema coverage, the description adds clear meaning to the single optional parameter 'keyword' with a concrete filter example ('ceo', 'founder'), which goes beyond the bare schema type and default.
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 lists executive tags for a specific search filter, distinguishing it from sibling tools like get_technographical_tags. The examples 'ceo', 'founder' add clarity, but the phrase 'for the executive_tags search filter' assumes familiarity with the broader API.
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 (for a search filter) but offers no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. No sibling comparisons or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List geographic precision levels used in the geo_levels search filter.
Returns codes and descriptions indicating the geocoding accuracy of a record (e.g. address-level, city-level, country-level).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the return values (codes and descriptions) and examples of accuracy levels. It lacks mention of rate limits or auth, but as a simple list tool, the transparency is adequate.
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 with no wasted words. The first sentence gives the action and context, the second clarifies the return values with examples.
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 zero-parameter tool with an output schema, the description fully explains what the tool does and the format of results. No gaps remain.
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 zero parameters, and schema coverage is 100% trivially. Baseline for 0 parameters is 4, and no additional parameter semantics are needed.
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 lists geographic precision levels for a specific filter, and specifies the return content (codes and descriptions). It is distinct from sibling get_* tools which handle other entity types.
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 the geo_levels search filter context. It does not explicitly exclude alternatives, but the purpose is clear enough that an agent would know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List import/export agent codes for the import_export_agent_codes search filter.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral disclosure. Only states it 'lists codes', lacking details on whether it is read-only, requires authentication, returns all codes, or any pagination. Insufficient for a tool with zero 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?
Single sentence conveying purpose efficiently. No unnecessary words; front-loaded with verb 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?
Given the tool is simple (0 params, output schema exists), the description is mostly adequate. Explains the purpose as a search filter, but omits context like whether the list is static or dynamic. Slightly incomplete for a complete picture.
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 has no parameters and 100% coverage trivially. Description adds no parameter info, but baseline is 3 due to high schema coverage. No additional meaning beyond schema needed, but could clarify that no parameters means all codes are returned.
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?
Clearly states the verb 'List' and the resource 'import/export agent codes', and specifies their role as a search filter. Distinguishes from sibling tools by naming the specific filter field, though could elaborate on the format or usage scenario.
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?
No guidance on when to use this tool versus alternatives. Does not mention that it is intended for populating a filter dropdown or that it returns static reference data. No exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available display languages for API results.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the tool returns a list, but does not disclose any other behavioral traits such as rate limits, authentication requirements, or return format details beyond what might be inferred from the 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 short sentence that is front-loaded and contains no redundant 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 has zero parameters, no nested objects, and an output schema is provided, the description is complete for agent understanding. It adequately explains the tool's purpose without additional details.
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 zero parameters, so schema coverage is 100%. Baseline for zero parameters is 4, and the description does not add parameter-specific information because none exist.
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 'List' and resource 'available display languages for API results', clearly distinguishing it from sibling tools that list other entities like countries or currencies.
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 when to use (to get display languages) but provides no explicit guidance on when not to use or alternatives. For a zero-parameter tool, usage is straightforward, but no exclusion conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List legal status codes (business legal forms) for a country.
Use the returned codes in the search_businesses legal_status_codes and
legal_status_codes_exclusive filters.
Args: country_code: ISO 3166-1 alpha-2 country code (e.g. "BE", "DE", "FR"). keyword: Optional keyword to filter results (e.g. "SA", "GmbH", "Ltd").
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | ||
| keyword | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool lists codes for a country and optionally filters by keyword, but does not explain output format, error handling, or behavior for invalid inputs.
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 concise: one sentence for purpose, followed by usage guidance and parameter explanations. No redundant information; each sentence 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?
For a simple list tool with 2 parameters and output schema present, the description covers purpose, usage context, and parameter semantics adequately. It does not explain output structure but output schema exists, so not required.
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 0%, but the description adds meaning: country_code is explained as ISO 3166-1 alpha-2 with examples, and keyword is explained as optional filter with examples. This compensates for the missing schema descriptions.
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 a specific verb 'list' and resource 'legal status codes (business legal forms)' for a country. It distinguishes from sibling tools like get_status_codes by specifying 'legal' status codes.
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 explicitly explains how the returned codes are used: in search_businesses filters. It provides clear context for when to use this tool, though it does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List national identification type codes for a country.
Use the returned codes in the search_businesses
national_identification_type_codes filter.
Args: country_code: ISO 3166-1 alpha-2 country code (e.g. "BE", "GB", "US").
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies a read-only operation by using 'List', but does not disclose error scenarios, rate limits, or response format. However, for a straightforward list tool, this is adequate.
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 composed of two concise sentences, front-loading the main purpose and following with usage guidance. No wasted words.
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?
The tool is simple with one parameter and an output schema exists (not shown). The description mentions the codes are for a filter, but doesn't describe the return structure. However, the output schema likely covers that, so it is mostly 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 coverage is 0%, so the description must compensate. It explains 'country_code: ISO 3166-1 alpha-2 country code (e.g. "BE", "GB", "US")', which adds format, examples, and context beyond the schema's simple 'string' type.
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 'List national identification type codes for a country' with a specific verb and resource. It distinguishes from sibling tools by focusing on national ID types, which is unique among the many 'get_*' siblings.
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 explicitly tells when to use the tool and how: 'Use the returned codes in the search_businesses national_identification_type_codes filter.' This provides clear downstream context and distinguishes it from other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List provinces for a country, optionally filtered by region code.
Use the returned codes as province_code in get_cities or search_businesses.
Args: country_code: ISO 3166-1 alpha-2 country code (e.g. "GB", "DE"). region_code: Optional region code from get_regions to narrow results. language_code: Display language for results (e.g. "en", "de", "fr").
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | ||
| region_code | No | ||
| language_code | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses required and optional parameters but does not describe output structure, error behavior, or any side effects. With an output schema present but not referenced, the description misses an opportunity to summarize return format.
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?
Extremely concise: one-line purpose, a usage hint, then structured Args list. Every sentence adds value with no redundant or vague language.
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 listing tool with 3 parameters and an output schema, the description covers purpose, parameters, and usage context. It could mention the output shape (list of province codes/names), but given the output schema existence, this is a minor gap.
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?
With 0% schema description coverage, the description adds crucial semantics: explains country_code as ISO 3166-1 alpha-2 with examples, region_code as coming from get_regions, and language_code as display language with examples. This goes well beyond the bare schema which only has titles and types.
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?
Description clearly states verb 'List' and resource 'provinces for a country' with optional region filter. It distinguishes from siblings by specifying how the returned codes are used in get_cities or search_businesses, making the tool's role in the ecosystem clear.
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?
Provides explicit usage context (list provinces, optionally filtered by region) and hints at next steps (using codes in other tools). However, lacks an explicit statement of when NOT to use this tool or direct comparison with siblings like get_cities or get_regions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full record for a business by country code and unique ID.
Args: country_code: ISO 3166-1 alpha-2 country code (e.g. "GB"). unique_id: Infobel unique ID for the business.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | ||
| unique_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states a 'get' operation, with no mention of error handling, permissions, rate limits, or idempotency. The behavior is assumed safe but not explicitly clarified.
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 exceptionally concise (three lines), front-loaded with the core purpose, and includes parameter details in a structured Args block. Every sentence adds value without redundancy.
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?
The tool has an output schema, so the description does not need to detail return values. It covers the essential inputs and purpose. However, it lacks any mention of error scenarios or limits, which would be useful for a full understanding.
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 0%, but the description adds clear meaning for both parameters: country_code is ISO 3166-1 alpha-2, unique_id is an Infobel unique ID. This compensates for the lack of schema descriptions, providing essential context beyond the raw 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 tool 'gets the full record for a business' filtered by country code and unique ID. It is specific about the resource (business record) and the inputs, distinguishing it from siblings like get_record_partial.
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?
No guidance is provided on when to use this tool versus alternatives such as get_record_partial or other search tools. There is no mention of prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a partial (lighter) record for a business.
Args: country_code: ISO 3166-1 alpha-2 country code (e.g. "GB"). unique_id: Infobel unique ID for the business.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | ||
| unique_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states 'partial (lighter) record' without explaining what is omitted, performance implications, or any side effects. This is insufficient for an agent to understand behavioral traits.
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 with two sentences for purpose and a separate line for each parameter. It front-loads the core purpose and avoids any unnecessary fluff.
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 presence of an output schema, return values are likely covered. However, the description lacks context about when to use this over 'get_record,' what constitutes 'partial,' and any performance or completeness trade-offs. It is adequate but not comprehensive.
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 schema description coverage is 0%, but the description adds meaning for both parameters: 'country_code: ISO 3166-1 alpha-2 country code (e.g. "GB").' and 'unique_id: Infobel unique ID for the business.' This goes beyond the schema's mere type and required status.
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: 'Get a partial (lighter) record for a business.' It specifies the verb 'Get' and the resource 'partial record for a business,' distinguishing it from the sibling 'get_record' by emphasizing 'partial.'
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 this tool is for lighter data compared to 'get_record,' but it does not explicitly state when to use this over alternatives, nor does it mention any when-not-to-use scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all regions for a country. Use the returned codes as region_code in get_provinces.
Args: country_code: ISO 3166-1 alpha-2 country code (e.g. "GB", "DE"). language_code: Display language for results (e.g. "en", "de", "fr").
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | ||
| language_code | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. States it is a list operation with no destructive action, but lacks details on rate limits or performance. Adequate for a simple read tool.
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 plus a structured Args section. No wasted words, front-loaded with main 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?
Output schema exists, so return values are documented elsewhere. Description includes downstream usage guidance, making it complete for a list tool.
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 has 0% description coverage, but the description explains country_code as ISO 3166-1 alpha-2 and language_code as display language with examples, adding meaning beyond the schema titles.
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 'List' and the resource 'all regions for a country', and distinguishes from siblings by specifying the downstream use in get_provinces.
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?
Explicitly says when to use the tool: to get region codes for use in get_provinces. No exclusion criteria, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List reliability codes and their meanings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic listing action. There are no annotations to rely on, so the description carries the full burden, but it adds no information about caching, ordering, or limitations.
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 very concise with a single sentence. It wastes no words, but it is also not structured in a way that highlights key points.
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) and the presence of an output schema (not shown), the description is minimally adequate. It states the basic purpose but could provide additional context, such as whether the list is static or dynamic.
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 no parameters, and the input schema covers 100% (trivially). According to the rubric, 0 parameters yields a baseline score of 4. The description does not add any parameter-specific semantics, but none are needed.
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 ('List') and the resource ('reliability codes') and mentions that it includes meanings, making the purpose clear. It is distinct from sibling get_* tools by specifying a unique resource.
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?
No guidance is provided on when to use this tool versus alternatives, such as other listing tools like get_languages or get_currencies. The description does not mention any context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated results from a previous search.
IMPORTANT — record_fields is required. Pass the same field list you used in search_businesses to get consistent, context-efficient results. uniqueID is always included automatically.
Args: search_id: Search ID returned by search_businesses. page: Page number (1-indexed). Pages must be fetched sequentially. record_fields: Fields to return per record. Must be non-empty. uniqueID is always included automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| search_id | Yes | ||
| page | Yes | ||
| record_fields | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral details (sequential pages, auto-included uniqueID) but omits error handling or output format details. The presence of an output schema reduces the burden.
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 concise, with a clear summary line and structured 'Args' section. Every sentence adds value, and it's front-loaded with the 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?
Given the sibling tools list and the presence of an output schema, the description covers the main usage constraints. It does not detail the output, but that is covered by the schema.
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 0%, so the description compensates fully: it explains that record_fields must be non-empty, uniqueID is automatic, and pages must be sequential. This adds essential meaning 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 tool retrieves paginated results from a previous search, specifying the required record_fields and noting that uniqueID is always included. This distinguishes it from sibling tools like search_businesses.
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 gives explicit guidance: pass the same field list as in search_businesses and fetch pages sequentially. It does not explicitly list when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a previous search.
Args: search_id: Search ID returned by search_businesses.
| Name | Required | Description | Default |
|---|---|---|---|
| search_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Check the status' but does not mention whether the operation is read-only, has side effects, or any rate limits. For a simple status check, the behavioral impact is minimal, but the description lacks explicit 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, with two short sentences and a parameter docstring. It immediately states the purpose and provides the necessary parameter context without any extraneous information.
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 that an output schema exists, the description does not need to explain return values. However, it does not mention what the output looks like or possible statuses, which could help. Overall, it is complete enough for a simple tool with one parameter and no complex behaviors.
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 single parameter search_id is documented in the schema as an integer. The description adds context by stating it is 'returned by search_businesses', which helps the agent understand the origin of the value. This compensates for the schema's lack of descriptive text (0% coverage) and makes the parameter semantics clear.
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 'Check the status of a previous search', specifying the verb (check) and resource (status of a search). It distinguishes from sibling tools like get_search_results by focusing on status, not results. However, it could be more specific about what status values are possible.
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 after search_businesses by referencing the search_id returned by that tool. However, it does not explicitly state when to use this tool versus alternatives like get_search_results, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported social media platforms for the social_links search filter.
Returns platform codes (e.g. "linkedin", "facebook") to use when filtering businesses by social media presence.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond basic functionality, such as whether the list is static or any read-only nature. However, the tool is simple and the description is adequate.
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 concise sentences, front-loaded with the key purpose, and contains no unnecessary words.
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, parameterless tool with an output schema, the description fully explains what the tool returns and how to use the output, making it contextually 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?
With no parameters, schema coverage is 100%. The description adds value by explaining the purpose of the output (returning platform codes for filtering), going beyond what the schema provides.
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 lists supported social media platforms for the social_links filter, using a specific verb and resource, and distinguishes it from siblings by its unique focus on social media platforms.
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 (to get platform codes for filtering), but does not explicitly mention alternatives or when not to use it, though the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available sorting order options for the sorting_order search parameter.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 accurately indicates a read-only retrieval operation ('List') with no hidden destructive effects or side effects. The behavior is transparent from the context.
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 conveys everything needed without extraneous words. It is front-loaded with the verb and resource, making it highly 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 zero parameters and the presence of an output schema, the description is fully adequate. It explains what the tool returns and its purpose, leaving no gaps for the agent to infer.
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 zero parameters, and schema description coverage is 100% (trivially). Per guidelines, 0 parameters sets a baseline of 4, and the description does not need to add parameter semantics.
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 ('List') and resource ('available sorting order options'), directly addressing the tool's purpose and distinguishing it from sibling tools like get_available_countries or get_cities.
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 states the use case: listing options for the 'sorting_order' search parameter. While no explicit when-not or alternatives are given, the context (zero parameters, single purpose) makes usage intuitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List business status / hierarchy codes and their meanings.
Returns the BusinessStatusCode enum values used in the search_businesses
status_codes and status_codes_exclusive filters. Values indicate the
physical location type: SingleLocation (0), HQ (1), Branch (2).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses what the tool returns (enum values with meanings). It is a read-only operation with no side effects mentioned. The description is sufficient for an agent to understand the behavior.
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 concise, with two short paragraphs. The first sentence states the purpose, and the rest provides specific detail about the values. No unnecessary words.
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?
The tool has an output schema (indicated), so the agent can understand the return format. The description covers the purpose, usage context, and exact values, making it complete for a simple enumeration tool.
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 no parameters, so schema coverage is 100%. The description does not need to provide parameter semantics as there are none.
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 'List business status / hierarchy codes and their meanings'. It specifies the purpose: returning BusinessStatusCode enum values used in search_businesses filters. The sibling tools are about other enumerations (countries, cities, etc.), making this tool's purpose distinct.
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 that the returned values are used as filters in search_businesses, implying usage when building search queries. While there are no explicit when-not or alternative tools, the context of many 'get_*' tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List technographic tags for the technographical_tags search filter.
Technographic tags identify web technologies used by a business (e.g. specific CMS, e-commerce platforms, analytics tools).
Args: keyword: Optional keyword to filter results (e.g. "shopify", "wordpress").
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as side effects, authentication needs, or whether the operation is read-only. It only states what the tool does, not its impact.
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 concise with three sentences, front-loading the purpose. Every sentence adds value without unnecessary repetition.
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 simplicity of the tool (1 optional parameter, output schema present), the description covers the essential aspects. Minor missing details like case sensitivity or result format are likely covered by the output schema.
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?
With 0% schema coverage, the description compensates well by explaining the 'keyword' parameter with examples ('shopify', 'wordpress') and stating it is optional for filtering.
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 it lists technographic tags for a search filter and explains what those tags are. It implicitly distinguishes from sibling tools like get_executive_tags by specifying the tag type.
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 populating the technographical_tags filter but does not explicitly state when not to use it or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List website status flags used in the website_status_flags search filter.
Returns integer codes and descriptions indicating the crawl/availability status of a business website.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the tool lists codes and descriptions, implying a read-only operation, but lacks details on permissions, rate limits, or any other behavioral traits beyond the basic output.
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, front-loaded with the purpose, and every sentence provides necessary information without redundancy.
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 parameters and the existence of an output schema, the description sufficiently explains what the tool returns (codes and descriptions) and its usage context. It could be slightly more detailed about the output, but overall it is 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?
There are no parameters, baseline is 4. The description adds value by explaining that the flags are used in a search filter and represent crawl/availability status, which is additional context beyond the empty 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 it lists website status flags used in a specific search filter, and specifies it returns integer codes and descriptions about crawl/availability status. This distinguishes it from sibling tools like get_available_countries or get_currencies.
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 mentions the tool is used in the 'website_status_flags' search filter, providing implicit context, but does not explicitly state when to use it over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Infobel worldwide business database.
IMPORTANT — record_fields is required. You MUST decide upfront which fields you need. Pass [] (empty list) for counts-only queries. uniqueID is always included automatically so callers can fetch full records.
Use-case examples for record_fields: Counts only (no records): record_fields=[] → Returns searchId + counts only (fastest, cheapest)
Name matching / deduplication: record_fields=["businessName", "tradeName", "companyName", "directoryName"]
Address verification: record_fields=["businessName", "address1", "address2", "postCode", "city", "province", "countryCode"]
Contact lookup: record_fields=["businessName", "phone", "email", "website"]
Full identity + location: record_fields=["businessName", "tradeName", "nationalID", "address1", "postCode", "city", "countryCode"]
Available field names (camelCase, as returned by the API): Identity: uniqueID, businessName, companyName, tradeName, directoryName, diasCode, nationalID, universalPublicationId Address: address1, address2, addressStreet, addressHouseNumber, postCode, city, cityCode, locality, localityCode, province, provinceCode, region, regionCode, country, countryCode Contact: phone, mobile, fax, email, website, webDomain, phoneOrMobile Corporate: yearStarted, employeesTotal, employeesHere, salesVolume, salesVolumeDollars, salesVolumeEuros, statusCode, statusCodeName, hierarchyCode, subsidiaryIndicator, importExportAgentCode, legalStatus Executive: ceoName, ceoTitle Geo: latitude, longitude, geoLevel, geoLevelDescription Digital: hasEShop, hasPayment, hasDigitalMarketing, hasShopTool, hasBuildingGeometry, hasMarketability, dncmPhone, websiteStatusFlag, websiteUUID, websiteIpAddress, websiteCrawlDate, webDomainUUID Linkage: parentLinkage, domesticLinkage, globalLinkage, familyMembers Categories: internationalCode01-06, infobelCode01-10, localCode01-15, altInternationalCode01-06, internationalCategories, altInternationalCategories Financial: financialHistory, salesVolumeReliabilityCode, employeesTotalReliabilityCode, employeesHereReliabilityCode Misc: language, reportDate, additionalInfos, genericSocialLinks
Returns JSON with: searchId — use with get_search_results for subsequent pages counts — total, hasPhone, hasEmail, etc. records — list of field-filtered records (empty when record_fields=[]) page — current page number (omitted when record_fields=[])
Args: country_codes: ISO 3166-1 alpha-2 country codes (e.g. ["GB", "DE"]). record_fields: Fields to return per record. Empty list = counts only. uniqueID is always included automatically. business_name: Business names to search for (e.g. ["Acme Corp"]). business_name_exclusive: Business names to exclude. national_id: National registration numbers to include. national_id_exclusive: National registration numbers to exclude. unique_ids: Infobel unique IDs to look up directly. unique_ids_exclusive: Infobel unique IDs to exclude. city_names: Filter by city names (e.g. ["London", "Manchester"]). city_codes: Filter by city codes. city_codes_exclusive: City codes to exclude. province_names: Filter by province/state names. province_codes: Filter by province codes. province_codes_exclusive: Province codes to exclude. region_names: Filter by region names. region_codes: Filter by region codes. region_codes_exclusive: Region codes to exclude. post_codes: Filter by postal/zip codes. post_codes_exclusive: Postal codes to exclude. street_address: Street address filter. house_number: House number filter. coordinate_latitude: Latitude for inclusive geo-search. coordinate_longitude: Longitude for inclusive geo-search. coordinate_distance: Radius in meters for inclusive geo-search (default 100). coordinate_latitude_exclusive: Latitude for exclusive geo-search. coordinate_longitude_exclusive: Longitude for exclusive geo-search. coordinate_distance_exclusive: Radius in meters for exclusive geo-search. phone_number: Phone numbers to include. phone_number_exclusive: Phone numbers to exclude. email: Email addresses to include. email_exclusive: Email addresses to exclude. website: Website URLs to include. website_exclusive: Website URLs to exclude. website_ip_address: Filter by website IP address. international_codes: ISIC international category codes to include. international_codes_exclusive: ISIC codes to exclude. infobel_codes: Infobel proprietary category codes to include. infobel_codes_exclusive: Infobel codes to exclude. local_codes: Local/national category codes to include (e.g. SIC, NAF). local_codes_exclusive: Local codes to exclude. alt_international_codes: NACE category codes to include. alt_international_codes_exclusive: NACE codes to exclude. categories_keywords: Free-text category keywords. restrict_on_main_category: When True, match only the primary category. has_address: Filter for businesses with an address. has_phone: Filter for businesses with phone numbers. has_fax: Filter for businesses with fax numbers. has_mobile: Filter for businesses with mobile numbers. has_email: Filter for businesses with email addresses. has_website: PresenceType for website: 0=Ignore, 1=Has, 2=HasNot. has_national_id: PresenceType for national ID: 0=Ignore, 1=Has, 2=HasNot. has_web_contact: Filter for businesses with website or email. has_contact: Filter for businesses with phone or mobile. has_coordinates: Filter for businesses with GPS coordinates. has_linked_in: Filter for businesses with LinkedIn profiles. has_logo: Filter for businesses with logos. has_admin: Filter for businesses with admin data. has_marketability: Filter for marketable records. has_building_geometry: Filter for records with building geometry. has_shop_tool: Filter for businesses with shop tools. has_payment: Filter for businesses with payment capabilities. has_digital_marketing: Filter for businesses with digital marketing. has_e_shop: Filter for businesses with e-shops. has_phone_deduplicated: Deduplicate on phone (requires has_phone). has_email_deduplicated: Deduplicate on email (requires has_email). has_website_deduplicated: Deduplicate on website (requires has_website). has_web_domain_deduplicated: Deduplicate on domain (requires has_website). has_national_id_deduplicated: Deduplicate on national ID. has_mobile_deduplicated: Deduplicate on mobile. has_contact_deduplicated: Deduplicate on contact. year_started_from: Minimum year started (e.g. "2000"). year_started_to: Maximum year started (e.g. "2020"). employees_total_from: Minimum total employee count (whole company). employees_total_to: Maximum total employee count (whole company). employees_here_from: Minimum employee count at this location. employees_here_to: Maximum employee count at this location. sales_volume_from: Minimum sales volume. sales_volume_to: Maximum sales volume. sales_volume_currency: Currency for sales volume (use get_currencies for codes). sales_volum_reliability_codes: Sales reliability codes to include. sales_volum_reliability_codes_exclusive: Sales reliability codes to exclude. family_members_from: Minimum family member count. family_members_to: Maximum family member count. is_published: Filter by published status on infobel.com. is_vat: Filter where NationalID is also a VAT number. filter_on_dncm: Exclude DoNotCallMe records (Belgium only). publishing_strength_from: Minimum publishing strength (0+). publishing_strength_to: Maximum publishing strength (max 100). linked_in_followers_from: Minimum LinkedIn followers. linked_in_followers_to: Maximum LinkedIn followers. status_codes: Business status codes for corporate hierarchy filtering. Use ["0"] for single-location independent companies (no corporate linkage — no parent, no subsidiaries). Use ["1"] for headquarters (HQ) of a corporate group. Use ["2"] for branches of a larger company. IMPORTANT: When searching for independent companies with no corporate linkage or subsidiaries, always include the appropriate status_codes to avoid returning corporate subsidiaries or branch offices. Choose based on the use case: - Fully independent single site → status_codes=["0"] - Group HQ only → status_codes=["1"] - Branch offices only → status_codes=["2"] - All with no parent filter → status_codes=["0","1","2"] Use get_status_codes to retrieve the full list. status_codes_exclusive: Business status codes to exclude. geo_levels: Geographic precision levels to include (use get_geo_levels). geo_levels_exclusive: Geographic precision levels to exclude. parent_unique_id: Filter by parent company unique ID. parent_unique_id_exclusive: Parent unique IDs to exclude. global_ultimate_unique_id: Filter by global ultimate owner unique ID. global_ultimate_unique_id_exclusive: Global ultimate unique IDs to exclude. global_ultimate_country_codes: Filter by global ultimate country codes. global_ultimate_country_codes_exclusive: Global ultimate country codes to exclude. domestic_ultimate_unique_id: Filter by domestic ultimate owner unique ID. domestic_ultimate_unique_id_exclusive: Domestic ultimate unique IDs to exclude. ceo_name: CEO/executive name search. ceo_title: CEO/executive title search. executive_tags: Filter by executive tags (use get_executive_tags for values). legal_status_codes: Legal form codes to include (use get_legal_status_codes). legal_status_codes_exclusive: Legal form codes to exclude. national_identification_type_codes: National ID type codes to include. national_identification_type_codes_exclusive: National ID type codes to exclude. import_export_agent_codes: Import/export agent codes to include. import_export_agent_codes_exclusive: Import/export agent codes to exclude. technographical_tags: Filter by web technologies (use get_technographical_tags). website_status_flags: Website status flags to include (use get_website_status_flags). website_status_flags_exclusive: Website status flags to exclude. social_links: Social media platforms to include (use get_social_links for codes). social_links_exclusive: Social media platforms to exclude. languages: ISO 639-3 language codes to include. languages_exclusive: ISO 639-3 language codes to exclude. can_match_any_business_filter: When True, OR logic instead of AND. try_any_location_match: Use partial location matches if exact not found. international_phone_format: Return phone numbers with +xxx prefix. validate_filters: Validate provided filters before searching. display_language: Language for result display (e.g. "en", "fr"). page_size: Results per page (default 20). sorting_order: Sorting options (use get_sorting_orders for values). data_type: Data type: "Business" (default), "YellowPages", or "WhitePages".
| Name | Required | Description | Default |
|---|---|---|---|
| country_codes | Yes | ||
| record_fields | Yes | ||
| business_name | No | ||
| business_name_exclusive | No | ||
| national_id | No | ||
| national_id_exclusive | No | ||
| unique_ids | No | ||
| unique_ids_exclusive | No | ||
| city_names | No | ||
| city_codes | No | ||
| city_codes_exclusive | No | ||
| province_names | No | ||
| province_codes | No | ||
| province_codes_exclusive | No | ||
| region_names | No | ||
| region_codes | No | ||
| region_codes_exclusive | No | ||
| post_codes | No | ||
| post_codes_exclusive | No | ||
| street_address | No | ||
| house_number | No | ||
| coordinate_latitude | No | ||
| coordinate_longitude | No | ||
| coordinate_distance | No | ||
| coordinate_latitude_exclusive | No | ||
| coordinate_longitude_exclusive | No | ||
| coordinate_distance_exclusive | No | ||
| phone_number | No | ||
| phone_number_exclusive | No | ||
| No | |||
| email_exclusive | No | ||
| website | No | ||
| website_exclusive | No | ||
| website_ip_address | No | ||
| international_codes | No | ||
| international_codes_exclusive | No | ||
| infobel_codes | No | ||
| infobel_codes_exclusive | No | ||
| local_codes | No | ||
| local_codes_exclusive | No | ||
| alt_international_codes | No | ||
| alt_international_codes_exclusive | No | ||
| categories_keywords | No | ||
| restrict_on_main_category | No | ||
| has_address | No | ||
| has_phone | No | ||
| has_fax | No | ||
| has_mobile | No | ||
| has_email | No | ||
| has_website | No | ||
| has_national_id | No | ||
| has_web_contact | No | ||
| has_contact | No | ||
| has_coordinates | No | ||
| has_linked_in | No | ||
| has_logo | No | ||
| has_admin | No | ||
| has_marketability | No | ||
| has_building_geometry | No | ||
| has_shop_tool | No | ||
| has_payment | No | ||
| has_digital_marketing | No | ||
| has_e_shop | No | ||
| has_phone_deduplicated | No | ||
| has_email_deduplicated | No | ||
| has_website_deduplicated | No | ||
| has_web_domain_deduplicated | No | ||
| has_national_id_deduplicated | No | ||
| has_mobile_deduplicated | No | ||
| has_contact_deduplicated | No | ||
| year_started_from | No | ||
| year_started_to | No | ||
| employees_total_from | No | ||
| employees_total_to | No | ||
| employees_here_from | No | ||
| employees_here_to | No | ||
| sales_volume_from | No | ||
| sales_volume_to | No | ||
| sales_volume_currency | No | ||
| sales_volum_reliability_codes | No | ||
| sales_volum_reliability_codes_exclusive | No | ||
| family_members_from | No | ||
| family_members_to | No | ||
| is_published | No | ||
| is_vat | No | ||
| filter_on_dncm | No | ||
| publishing_strength_from | No | ||
| publishing_strength_to | No | ||
| linked_in_followers_from | No | ||
| linked_in_followers_to | No | ||
| status_codes | No | ||
| status_codes_exclusive | No | ||
| geo_levels | No | ||
| geo_levels_exclusive | No | ||
| parent_unique_id | No | ||
| parent_unique_id_exclusive | No | ||
| global_ultimate_unique_id | No | ||
| global_ultimate_unique_id_exclusive | No | ||
| global_ultimate_country_codes | No | ||
| global_ultimate_country_codes_exclusive | No | ||
| domestic_ultimate_unique_id | No | ||
| domestic_ultimate_unique_id_exclusive | No | ||
| ceo_name | No | ||
| ceo_title | No | ||
| executive_tags | No | ||
| legal_status_codes | No | ||
| legal_status_codes_exclusive | No | ||
| national_identification_type_codes | No | ||
| national_identification_type_codes_exclusive | No | ||
| import_export_agent_codes | No | ||
| import_export_agent_codes_exclusive | No | ||
| technographical_tags | No | ||
| website_status_flags | No | ||
| website_status_flags_exclusive | No | ||
| social_links | No | ||
| social_links_exclusive | No | ||
| languages | No | ||
| languages_exclusive | No | ||
| can_match_any_business_filter | No | ||
| try_any_location_match | No | ||
| international_phone_format | No | ||
| validate_filters | No | ||
| display_language | No | ||
| page_size | No | ||
| sorting_order | No | ||
| data_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully cover behavioral traits. It does not mention read-only nature, rate limits, authentication requirements, or side effects. It only explains return values (searchId, counts, records, page) but omits basic safety/behavioral info.
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 about 2000 words, far too verbose. While it front-loads critical info (record_fields requirement and examples), the parameter list is repetitive and bloated. Could be substantially shortened without losing meaning.
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 (126 parameters, no schema descriptions, output schema exists), the description covers parameter usage and return structure but lacks behavioral context like read-only flag or authentication. It is adequate but not 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 0%, so the description carries full burden. It adds significant value by organizing parameters into categories (Identity, Address, Contact, etc.) and providing use-case examples for record_fields. However, the parameter list is lengthy and many parameters get only one-line explanations.
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 starts with a clear verb+resource: 'Search the Infobel worldwide business database.' It explains that it searches for businesses with many filters, which distinguishes it from siblings like get_record (single record) and get_search_results (pagination). However, it does not explicitly contrast with all sibling tools.
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 important guidance: record_fields is required, empty list for counts-only, uniqueID always included, and use-case examples for record_fields. It does not explicitly state when not to use this tool or offer alternatives like get_record for full records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search NACE codes (European standard, AltInternational) by one or more keywords.
Each keyword triggers a separate API call; results are merged and deduplicated.
Returns matching NACE codes for use in search_businesses alt_international_codes
field. Use this for EU industry classification queries.
Args: keywords: One or more search terms (e.g. ["computer programming"], ["software", "IT", "development"]). language_code: Display language for results (e.g. "en", "fr", "de").
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | ||
| language_code | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that each keyword triggers a separate API call and results are merged/deduplicated, which is critical behavioral information. It does not mention side effects or rate limits, but the given detail adds significant value beyond the 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 concise, with the first sentence stating the purpose, followed by behavioral details and usage context. The Args section is structured clearly. No unnecessary words exist.
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 presence of an output schema and the tool's search functionality, the description covers purpose, behavior (multi-call, merge), usage domain, and parameter details. It sufficiently informs an AI agent without missing critical aspects.
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 0%, so the description must compensate. It provides detailed parameter descriptions with examples for both keywords and language_code, including default values and usage context, fully covering the meaning of each parameter.
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 searches NACE codes (European standard) by keywords, differentiates from sibling tools like search_categories_infobel and search_categories_local by specifying EU industry classification, and mentions the specific classification system (AltInternational). This provides a specific verb and resource with clear distinction.
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 explicitly states 'Use this for EU industry classification queries' and notes the results are intended for the search_businesses tool's field, providing clear usage context. However, it does not explicitly exclude alternatives or mention when not to use it, so a slight deduction for lacking exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Infobel's proprietary category hierarchy by one or more keywords.
Each keyword triggers a separate API call; results are merged and deduplicated.
Use multiple keywords to widen coverage — e.g. ["plumbing", "plumber", "pipes"].
Returns matching categories with their codes for use in search_businesses
infobel_codes field.
Args: keywords: One or more search terms (e.g. ["restaurant"], ["computer", "software", "IT"]). language_code: Display language for results (e.g. "en", "fr", "de").
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | ||
| language_code | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: each keyword triggers a separate call, results are merged and deduplicated, and output includes codes for use in another tool. It lacks mention of read-only nature or rate limits, but overall provides meaningful behavioral insight.
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 well-structured with purpose, usage advice, and parameter details. It is mostly concise, though the Args section repeats information from the parameter names. Minor redundancy but overall 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?
The description covers purpose, behavior, parameter usage, and output purpose. It mentions the link to search_businesses. Given an output schema exists, it does not need to detail return format further. Slightly lacking mention of safety (read-only) but otherwise 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 coverage is 0%, but the description explains both parameters thoroughly: keywords as an array of search terms with examples, and language_code as display language with common codes. It adds value beyond the schema alone.
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 searches Infobel's proprietary category hierarchy by keywords, explains the multi-keyword behavior with separate API calls and deduplication, and explicitly links the output to use in search_businesses. This distinguishes it from siblings for other category sources.
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 advises using multiple keywords to widen coverage and provides examples. It mentions the output's purpose for search_businesses, implying context. However, it does not explicitly compare to sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ISIC international category codes (UN standard) by one or more keywords.
Each keyword triggers a separate API call; results are merged and deduplicated.
Returns matching codes for use in search_businesses international_codes field.
Use for cross-country industry searches using UN classification.
Args: keywords: One or more search terms (e.g. ["manufacturing"], ["retail", "wholesale", "trade"]). language_code: Display language for results (e.g. "en", "fr").
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | ||
| language_code | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that each keyword triggers a separate API call and results are merged and deduplicated. It also states that returned codes are for use in search_businesses field. Since no annotations are provided, this behavior information is valuable, though it does not cover rate limits or auth.
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 concise with no wasted words. It is front-loaded with the main action, followed by behavioral details, use case, then parameter explanations. Structure is logical.
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 an output schema exists (not shown), the description need not explain return values. It covers purpose, behavioral quirks, and parameter usage adequately for a simple search tool, though it omits edge cases like error handling or pagination.
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 'Args' section explains both parameters: keywords as search terms with examples, language_code as display language with examples. Schema coverage is 0%, so the description fully compensates by providing meaning beyond the schema fields.
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 it searches ISIC international category codes (UN standard) by keywords. It distinguishes from siblings by specifying 'ISIC international' and 'UN standard', differentiating it from alternative category searches like alt_international, infobel, local.
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 says 'Use for cross-country industry searches using UN classification.' While this provides context, it does not explicitly state when not to use or mention sibling tools as alternatives, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search country-specific category codes by one or more keywords.
Each keyword triggers a separate API call; results are merged and deduplicated.
Returns matching local codes (e.g. SIC for US, NAF for France, WZ for Germany)
for use in search_businesses local_codes field.
Args: keywords: One or more search terms (e.g. ["plomberie"], ["bakery", "boulangerie", "pastry"]). country_code: ISO 3166-1 alpha-2 country code (e.g. "FR", "DE", "US"). language_code: Display language for results (e.g. "en", "fr").
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | ||
| country_code | Yes | ||
| language_code | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on full responsibility. It discloses that each keyword triggers a separate API call and that results are merged and deduplicated. This is valuable behavioral insight. It could mention if there are limits on keyword count or pagination, but given the output schema exists, it's adequate.
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 concise and well-structured. It starts with the main purpose, then adds behavioral detail, then lists parameters. Every sentence adds value, and the Args block is cleanly formatted. No wasted words.
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 (multi-keyword search, country-specific codes, integration with search_businesses), the description provides sufficient context: merging behavior, use case, parameter details. It leverages the output schema for return structure. Could mention whether there are limits on the number of keywords, but overall very informative.
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 0%, so the description must provide parameter meanings. It does so clearly in the Args block: explains keywords as search terms with examples, country_code as ISO alpha-2, and language_code with default. The examples ('plomberie', 'bakery', 'boulangerie') add clarity.
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 it searches country-specific category codes by keywords. It uses a specific verb ('Search') and resource ('country-specific category codes'). However, it does not explicitly differentiate from sibling tools like search_categories_international or search_categories_alt_international, missing an opportunity to clarify its unique scope.
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 the tool's purpose and provides a usage example (e.g., for search_businesses local_codes field). It mentions each keyword triggers a separate API call, which helps set expectations. However, it does not explicitly state when not to use this tool or list alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cities, regions, and provinces within a country by one or more keywords.
Each keyword triggers a separate API call; results are merged and deduplicated. Returns matching location codes for use in search_businesses filters (city_codes, region_codes, province_codes). Always use this instead of fetching full location lists.
Args: keywords: One or more search terms (e.g. ["Munich"], ["Bavaria", "Bayern", "Munich"]). country_code: ISO 3166-1 alpha-2 country code (e.g. "DE", "GB"). language_code: Display language for results (e.g. "en", "de", "fr").
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | ||
| country_code | Yes | ||
| language_code | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavioral traits. It discloses that multiple keywords trigger separate API calls with merging and deduplication, which is useful. However, it does not specify whether the operation is read-only, any authentication requirements, rate limits, or error handling behavior, leaving gaps 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 well-structured with a clear opening sentence defining the purpose, followed by behavioral details and parameter explanations in a bullet-like format with examples. It is concise but could be slightly tighter by removing redundant phrasing, though it remains effective.
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 an output schema (context signal), the description does not need to detail return values; it adequately states that matching location codes are returned for use in filters. The parameter explanations are complete, and the usage guidance is sufficient for an agent to correctly invoke the tool.
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?
Given 0% schema description coverage, the description adds significant meaning: it explains that keywords are one or more search terms with examples, country_code follows ISO 3166-1 alpha-2, and language_code controls display language with a default. This fully compensates for the schema's lack of 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 explicitly states it searches cities, regions, and provinces within a country by keywords, and distinguishes itself from sibling tools like get_cities and get_regions by noting it returns filtered codes for use in search_businesses filters, recommending its use over fetching full lists.
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?
It provides clear context on when to use the tool (to obtain location codes for filtering search_businesses) and advises against using full location lists instead. However, it does not explicitly mention cases where this tool should not be used or provide alternative sibling tools for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify API connectivity and authentication.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 disclosing behavioral traits. It only states the action without explaining what happens on success/failure, authentication methods, or side effects. This is insufficient for a tool with no annotations.
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, using a single sentence that is front-loaded with the verb and object. There is no wasted text.
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, clear purpose) and the presence of an output schema documenting return values, the description covers the essential context. It could mention that it is safe to call repeatedly, but it is mostly 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?
The input schema has no parameters, so schema_description_coverage is effectively 100%. The description does not add parameter information, but none is needed. Baseline 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 tool's purpose: verifying API connectivity and authentication. It uses a specific verb ('Verify') and resource ('API connectivity and authentication'), and it distinguishes itself from sibling tools that focus on data retrieval or searches.
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 the tool is for testing connectivity before other operations, but it does not explicitly state when to use it vs. alternatives or provide any 'when-not-to-use' guidance. For a simple health-check tool, this is minimally adequate but lacks explicit direction.
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.1.0search_businesses2 fields changedInput schema / properties / employees_here_fromAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Employees Here From"
+}Input schema / properties / employees_here_toAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Employees Here To"
+}v1.0.6get_available_countriesget_citiesget_currenciesget_executive_tagsget_geo_levelsget_import_export_agent_codesget_languagesget_legal_status_codesget_national_id_typesget_provincesget_recordget_record_partialget_regionsget_reliability_codesget_search_resultsget_search_statusget_social_linksget_sorting_ordersget_status_codesget_technographical_tagsget_website_status_flagssearch_businessessearch_categories_alt_internationalsearch_categories_infobelsearch_categories_internationalsearch_categories_localsearch_locationstest_connectionMost tools have clearly distinct purposes, but there is potential confusion between get_cities and search_locations (both deal with geographic entities) and between get_record and get_record_partial. The descriptions are thorough, helping disambiguate, but the overlap is noticeable.
Tool names follow a consistent verb_noun pattern with snake_case (e.g., get_*, search_*, test_*). No mixing of styles or vague verbs, making the naming predictable and easy to understand.
28 tools is slightly above the typical 3-15 range, but the complexity of the Infobel business database justifies this number. The tools are well-scoped to the domain, and each serves a clear purpose without being excessive.
The tool set covers the core query and filter functionalities comprehensively, including reference data retrieval, category searches, and pagination. However, it lacks write operations (create/update/delete), which is acceptable for a read-oriented API. Minor gaps might include batch operations or advanced analytics.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Live Google Maps business search, review, and photo data for AI agents over MCP.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/techinfobel/infobel-getdata-api-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
