Skip to main content
Glama

Find companies

find_companies
Read-only

Find companies by BUYING SIGNALS and firmographics — hiring now, fast-growing headcount, revenue band, new leadership, and/or recently funded — optionally scoped by industry, HQ location, and size. FREE (no credits). Returns each company's name, companyId, industry, and size. Combine signals to sharpen: hiring, growingTeamMinPct, revenue and size are ALL required together (e.g. hiring:true + recentFunding:true = hiring AND just raised). LinkedIn can't require recentFunding AND recentLeadershipChange in one search, so asking for both runs each separately and lists companies that have both first — every row then carries signals:[…] and the result says how many have both. The next step is to reach people there: search_people with companyIds:[the returned companyId values] plus seniorities (and changedJobs / postedOnLinkedIn for timing), or find_decision_makers("") for one company (those pull rows and cost credits). Runs on LinkedNav's shared search database — no account needed. (Note: filtering by which SOFTWARE a company uses is not available on the current data tier.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax companies to return (1–100, default 20). Use 100 to feed the most companies to search_people via companyIds.
hiringNoOnly companies with open job posts right now (hiring signal).
locationsNoCompany HQ locations, e.g. ["United States"].
headcountsNoCompany size bands. Valid: self-employed, 1-10, 11-50, 51-200, 201-500, 501-1000, 1001-5000, 5001-10000, 10001+.
industriesNoCompany industries, e.g. ["Software","Financial Services"].
recentFundingNoOnly companies with a recent funding event (same as list_funding_signals).
revenueCurrencyNoCurrency for the revenue band (default USD).
growingTeamMinPctNoMinimum headcount-growth percent, e.g. 20 = teams that grew ≥20%.
maxRevenueMillionsNoMaximum annual revenue in millions (same brackets).
minRevenueMillionsNoMinimum annual revenue in millions (e.g. 10 = $10M+). LinkedIn uses fixed brackets (0, 0.2, 1, 2.5, 5, 10, 20, 50, 100, 500, 1000); other values widen to the nearest one. Revenue is LinkedIn's estimate — companies without one are left out.
recentLeadershipChangeNoOnly companies with a recent senior-leadership change (new-boss signal).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover safety (readOnly, non-destructive, openWorld), and the description adds substantial behavior the annotations cannot: it is free/no-credits, needs no account, and runs on a shared database. It also discloses signal-combination limits (hiring/growingTeamMinPct/revenue/size must ALL be given together) and the LinkedIn restriction that recentFunding + recentLeadershipChange runs two searches and adds a signals:[...] field.

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?

The purpose and the primary routing are front-loaded, and most sentences carry unique constraints. It is dense and long for a single paragraph, packing several distinct concerns (limits, combination rules, next steps, unavailability), but little of it is filler.

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

Completeness5/5

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

For an 11-param, no-output-schema search tool, it covers return fields (name, companyId, industry, size), the follow-on workflow, cost model, and behavioral quirks. An agent has everything needed to invoke it correctly and act on results.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains how signals combine (hiring:true + recentFunding:true = AND) and that some parameters are only valid together, which the per-field schema text does not convey.

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

Purpose5/5

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

Opens with a specific verb+resource: 'Find companies by BUYING SIGNALS and firmographics' and enumerates the signals (hiring, growth, revenue, leadership, funding) plus optional scoping. It clearly distinguishes itself from search_people, find_decision_makers, and list_funding_signals by naming them and their roles.

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

Usage Guidelines5/5

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

Explicit when-to-use with routing: it states the tool is FREE, frames it as the step before search_people/find_decision_makers, and warns those pull rows and cost credits. It also excludes the unavailable use case ('filtering by which SOFTWARE a company uses is not available'), which is exactly the kind of negative guidance that prevents misselection.

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.