Skip to main content
Glama

Chercher des personnes

basile_search_people
Read-onlyIdempotent

Cherche des PERSONNES/contacts (dirigeants légaux + profils LinkedIn) dans Basile. Renvoie { total, leads[], pagination.nextToken }. Utilise nextToken pour paginer. limit défaut 25, max 1000. La page > 1 nécessite un abonnement actif (402 sinon). ⚠️ COÛT : 1 crédit par fiche renvoyée (donc limit=25 → 25 crédits), à chaque appel, sans déduplication d'un appel à l'autre. Compte d'abord avec basile_count (gratuit), et ne demande que le nombre de fiches réellement utile. Le total renvoyé ici est plafonné à 100 000 : pour un volume exact, utiliser basile_count.

FORME DES FILTRES :

  • Filtre texte = {"include":[...], "exclude":[...]} — include = OR, exclude = NOT.

  • Plusieurs filtres différents = ET entre eux.

  • People : filtres numériques = range objet {">=":n,"<=":n} (ops >, >=, <, <=).

  • Companies : filtres numériques = champs simples _min / _max (ex. capital_min, headcount_max).

FILTRES PEOPLE (POST /people/find) : Communs (2 sources Legal + LKI) : activity (secteur/métier de l'entreprise de la personne — IDs concept via basile_activity_suggest, ou préfixes naf:/lki:/gmb:), result_full_name, result_last_name, result_first_name, result_role (intitulé de poste, TEXTE → mettre toutes les variantes ; ex. CEO+PDG+Directeur Général…), result_city, region (RÉGION française canonique, ex "Île-de-France" — couvre Legal+LKI), result_country, result_country_code (ex. "FR"), employer. Legal-only (activer = exclut LinkedIn) : mandate_role (gerant|president|dg|dgd|administrateur|commissaire_comptes|associe|directeur_non_dg|autre), result_used_first_name, result_postal_code, siren, legal_name, nationality, nationality_code, result_is_legal_entity (bool), result_is_current (bool, mandat actuel), result_age (range), result_total_companies_count (range). LinkedIn-only (activer = exclut Legal) : current_seniority (C-Level|Director|VP|Head|Manager|Senior|Partner|Owner|Founder|Entry|Training|Unpaid), current_job_functions, skills, languages, education, past_title, past_employer, tenure_bucket, past_tenure_bucket, current_tenure_years (range, ancienneté au poste ACTUEL en années — plus fin que tenure_bucket), connection_count (range), linkedin_url (retrouver un profil par son URL/handle LinkedIn — à coupler avec source:"LKI"). Taille de l'employeur (MULTI-SOURCE, n'exclut aucune source) : company_headcount (range) — effectif de la société ACTUELLE du contact, croisant l'effectif exact du registre légal et la bande de taille déclarée sur LinkedIn. C'est LE filtre pour « dirigeants de PME de 50 à 200 personnes » ; ne pas le confondre avec un filtre sur les entreprises. Les fiches sans effectif connu sont exclues (~21 % sur un échantillon FR). Pilotage source : source ("Legal"|"LKI"), with_legal_data (bool), with_linkedin_profile (bool), hide_legal_entities (bool, RECOMMANDÉ par défaut pour ne lister que de vraies personnes). CONSEILS : secteur → activity direct, taille d'entreprise → company_headcount direct. NE JAMAIS enchaîner une recherche entreprises puis une recherche personnes pour filtrer par secteur ou par taille : ces deux filtres font le travail en UNE requête. Le workflow entreprises→personnes est un fallback, réservé au cas où l'on part d'entreprises nommées ou de fiches Google. France → result_country_code:{include:["FR"]}. Dirigeants actifs → result_is_current:true. NB : le total people = somme LKI+Legal (peut sur-compter une personne présente dans les 2 sources) → meta.totalBySource + totalEstimated l'indiquent ; compter avant d'extraire.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNb de résultats à renvoyer (défaut 25).
filtersYesFiltres people (voir description).
paginationTokenNoCurseur `pagination.nextToken` de la page précédente.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNb de fiches réellement renvoyées dans cette page (= crédits débités).
leadsYesLes personnes de cette page.
totalYesTotal, PLAFONNÉ à 100 000 — pour l'exact, utiliser basile_count.
nextTokenYesCurseur de la page suivante ; null quand il n'y en a plus.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description goes far beyond by disclosing the 1-credit-per-record cost, the 402 error for page > 1 without a subscription, the total capped at 100,000, the ~21% exclusion of records without headcount, and the over-counting when a person exists in both LKI and Legal sources. This is rich behavioral context that annotations alone cannot provide, and there is no contradiction.

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 description is long (~1000 words), but it is well-structured with clear sections (FORME DES FILTRES, FILTRES PEOPLE, Legal-only, LinkedIn-only, Taille de l'employeur, Pilotage source, CONSEILS), and the most critical operational facts (cost, pagination, subscription) are front-loaded before the filter catalog. The length is justified by the tool's complexity and the generic schema. A slight deduction because the CONSEILS section partially restates guidance already implied earlier.

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 a tool with high complexity (many filters, two data sources, cost model, pagination, output schema), the description is essentially complete: return format, pagination cursor semantics, cost per call, subscription gating, total capping, filter syntax, all field names, source control, and actionable tips. Nothing an agent needs to call it correctly is missing, and the output schema covers the response shape.

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?

Although schema description coverage is 100%, the filters property in the schema merely says 'Filtres people (voir description)' — a pointer. The description carries the full burden: the include/exclude format, OR/NOT semantics, AND between filters, the range object form for people numeric filters vs _min/_max for company filters, and the complete list of Legal-only and LinkedIn-only fields. This adds substantial meaning far beyond the sparse schema.

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?

The description states a specific verb ('Cherche des PERSONNES/contacts'), the exact resource (dirigeants légaux + profils LinkedIn), and the return shape ({ total, leads[], pagination.nextToken }). It explicitly differentiates from the sibling basile_search_companies and names basile_count as the counting alternative. An agent can immediately tell what this tool does and what it does not do.

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?

Extremely explicit usage guidance: use basile_count first (free) before extracting, use nextToken for pagination, page > 1 requires an active subscription, and the cost implication of limit. It also states when NOT to use a particular workflow ('NE JAMAIS enchaîner une recherche entreprises puis une recherche personnes'), naming basile_activity_suggest and basile_search_companies as alternatives. Nothing is left to inference.

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.

Resources