Skip to main content
Glama

Openapi®

Search italian companies by advanced search criteria

get_company_IT_search
Read-onlyIdempotent

Returns a list of italian companies based on the search criteria. Use this tool if you don't know the VAT number of a company. Use this tool with dryRun=1 and no limit parameter to get the count of available results for the matching criterias Use this tool if you need to extract enriched data (max 1000 records paginable with the skip parameter) like name, address, pec, start (all the data in the get_company_IT_start tool) or advanced (all the data in the get_company_IT_advanced tool) based on matching criterias. Args: companyName: The name or part of it of an Italian company (optional). provinceCode: The 2 letters provinceCode where the company is located to restrict the results (optional). skip: The number of records to skip for pagination (optional). limit: The maximum number of results to return (optional, default is 10), if you want to have the total count of records with matching criterias skip this parameter and set dryRun to 1. dataEnrichment: Avoid further queries receiving Additional data enrichment options in the results (default is name), multiple values are forbidden, Available values : start, advanced, pec, address, shareholders, name legalFormCode: Filter by legalformcode of the company (optional). For Available values use get_company_IT_legal_forms_list tool, multiple values are forbidden, possible values: ["EI","EL","OO","OS","RC","ST","AF","AP","AS","CO","EE","FO","SL","SR","SZ","AL","AN","CC","CF","EC","ED","EN","OC","PA","SF","SO","AA","AC","AI","AM","AT","CR","ES","GE","IF","LL","RS","SI","AR","CS","SA","SC","SD","SG","AE","EP","PF","SN","SP","XX","AU","CE","CI","CL","CN","CZ","DI","RR","SE","SU","AZ","CM","EM","ER","FI","IC","ID","IR","MA","PC","PS","SM","SS","SV"] startDate: Filter by the start date of the company (optional). endDate: Filter by the end date of the company (optional). dryRun: Simulates a request by returning only the number of records "count" found and the price "cost" (optional) Available values :0,1. lat: Latitude for geographical search (optional). long: Longitude for geographical search (optional). radius: Radius in meters for geographical search (optional). autocomplete: Search for strings that begin with the specified query (optional). townCode: The cadastral code for the town (optional). atecoCode: ATECO code for the company (optional). cciaa: Chamber of Commerce code (optional). reaCode: REA code (optional). minTurnover: Minimum turnover value (optional). maxTurnover: Maximum turnover value (optional). minEmployees: Minimum number of employees (optional). maxEmployees: Maximum number of employees (optional). sdiCode: SDI code (optional). shareHolderTaxCode: Tax code of a company member (optional). activityStatus: Status of the company in the Chamber of Commerce (optional), Available values : ATTIVA, CESSATA, REGISTRATA, INATTIVA, SOSPESA, IN_ISCRIZIONE. pec: PEC email address of the company (optional). creationTimestamp: Filter by creation unix timestamp (optional). lastUpdateTimestamp: Filter by last update unix timestamp (optional).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNo
pecNo
longNo
skipNo
cciaaNo
limitNo
dryRunNo
radiusNo
endDateNo
reaCodeNo
sdiCodeNo
townCodeNo
atecoCodeNo
startDateNo
companyNameNo
maxTurnoverNo
minTurnoverNo
autocompleteNo
maxEmployeesNo
minEmployeesNo
provinceCodeNo
legalFormCodeNo
activityStatusNo
dataEnrichmentNoname
creationTimestampNo
shareHolderTaxCodeNo
lastUpdateTimestampNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this readOnly/idempotent/openWorld=false, so the safety profile is covered. The description adds real behavioral value beyond that: a 1000-record cap, skip-based pagination, and the dryRun count+cost simulation, which an agent needs to plan calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads usage guidance before the arg list, which is the right order. It is long, and some per-parameter lines are thin ('...is optional', 'The cadastral code for the town'), but the size is defensible for a 27-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description briefly covers returns (a list, enriched when dataEnrichment is set, or a count/cost under dryRun). For a 27-param search tool this is nearly complete; only the exact shape of the returned records is left implicit.

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

Parameters5/5

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

With 0% schema description coverage, the description carries the entire burden and does so for essentially all 27 params, including 'multiple values forbidden' constraints, the dataEnrichment default and allowed values, and enum-style hints for legalFormCode and activityStatus.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Returns a list of italian companies based on search criteria') and clarifies its role versus the VAT-number path. It references siblings get_company_IT_start and get_company_IT_advanced as sources of the enrichment payloads, giving partial sibling differentiation rather than a crisp full separation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Offers several concrete when-to-use conditions: when you don't know the VAT number, when you want a count via dryRun=1 with no limit, and when you need enriched data. It implies but never names the alternative for the case where you DO know the VAT number, so the guidance is clear context without a complete when-not branch.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.