insourcia

create_saved_search

Idempotent

Creation d'une recherche sauvegardee pour l'utilisateur, visible dans l'app Insourcia (page /news - Veille).

Utiliser cet outil quand l'utilisateur veut SAUVEGARDER une recherche pour la suivre dans le temps (veille marche, suivi d'un secteur, pipeline de cibles) - pas pour une recherche ponctuelle (utiliser search_companies).

Fonctionnement :

Les filtres acceptes sont les MEMES que search_companies (query texte libre + filtres geographie/secteur/financier/dirigeants/groupe + advanced_filters JSON). Au moins un critere est requis.
Idempotent : si une recherche sauvegardee ACTIVE du meme nom existe deja pour l'utilisateur, elle est renvoyee telle quelle (already_exists=true), sans doublon et sans modifier son alerte.
enable_alert=true active une alerte quotidienne : l'utilisateur est notifie (page /news + email) quand de NOUVELLES societes entrent dans les criteres de la recherche. A la creation, une notification initiale recapitule les societes entrees dans les 90 derniers jours ; ensuite seules les entrees futures declenchent.

Reponse : { id, name, url (page /news), result_count (nombre de societes matchant actuellement, null si indisponible), filters (filtres normalises stockes, absent sur le hit idempotent), already_exists, alert_enabled }.

Apres creation, communiquer l'URL a l'utilisateur pour qu'il retrouve sa veille dans l'app.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Nom de la recherche sauvegardee, court et parlant. Ex: "SaaS Bretagne CA > 5M". 1-255 caracteres.
`query`	No	Nom, SIREN, mot-cle activite, ou "*" pour rechercher uniquement par filtres
`ville`	No	Nom de ville. Plusieurs villes separees par virgule. Ex: "Paris,Lyon,Bordeaux"
`ca_min`	No	CA minimum en euros. Ex: 5000000 pour 5M
`radius`	No	Rayon de recherche en km (1-200) autour de latitude/longitude. Les trois vont ensemble : un triplet incomplet est refuse.
`region`	No	Region. Ex: "Ile-de-France", "Bretagne", "Auvergne-Rhone-Alpes"
`statut`	No	Filtre par statut au registre. DISSOLVED = dissoute ou radiee ; une societe en procedure collective reste ACTIVE jusqu'a sa radiation. Le statut ne se deduit PAS de date_radiation, absente sur environ 9,9M des 12,4M societes dissoutes.
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
`code_naf`	No	Code NAF/APE. Exemples courants : - SaaS/Logiciel : 5829C, 6201Z, 6202A - Conseil IT : 6202A, 6209Z - Conseil management : 7022Z - Fintech : 6419Z, 6499Z - Biotech/Pharma : 2120Z, 7211Z - E-commerce : 4791A, 4791B - BTP : 4120A, 4120B - Restauration : 5610A, 5610C Plusieurs codes separes par virgule.
`is_cotee`	No	true pour les societes cotees en bourse uniquement, false pour les exclure
`latitude`	No	Latitude du centre pour une recherche par rayon (WGS84). A fournir avec longitude ET radius.
`longitude`	No	Longitude du centre pour une recherche par rayon (WGS84). A fournir avec latitude ET radius.
`cagr_ca_min`	No	Croissance CA min sur 1 an en % (ex: 20 pour +20%)
`code_postal`	No	Code postal du siege. Ex: "75001", "69001". Plusieurs separes par virgule.
`departement`	No	Code departement. Ex: "75", "33", "69"
`est_filiale`	No	true = filiales uniquement, false = entreprises independantes uniquement
`has_website`	No	true pour ne retourner que les entreprises ayant un site web
`effectif_min`	No	Effectif minimum (nombre de salaries)
`enable_alert`	No	true pour etre notifie quotidiennement des nouvelles societes qui matchent la recherche. Defaut: false.
`filter_annee`	No	Annee de l'exercice financier. Filtre les entreprises dont le dernier bilan publie correspond a cette annee. Ex: 2024 pour ne voir que les bilans 2024. Combiner avec ca_min pour "societes ayant fait 5M de CA en 2024".
`siren_groupe`	No	SIREN de la tete de groupe. Retourne toutes les societes du meme groupe. Ex: "352383715" pour lister toutes les filiales de LVMH.
`dirigeant_nom`	No	Nom de famille du dirigeant (recherche exacte). Ex: "GUILLEMOT". Combine avec dirigeant_prenom et dirigeant_naissance pour desambiguiser les homonymes.
`groupe_parent`	No	Nom du groupe parent (recherche textuelle). Ex: "LVMH", "Bouygues"
`plan_en_cours`	No	Societes executant un plan (redressement, sauvegarde ou cession). Distinct de procedure_collective : sous plan, la periode d'observation est terminee.
`tresorerie_min`	No	Tresorerie minimum en euros
`advanced_filters`	No
`dirigeant_prenom`	No	Prenom du dirigeant. A utiliser avec dirigeant_nom. Ex: "Yves"
`resultat_net_min`	No	Resultat net minimum en euros
`age_dirigeant_max`	No	Age maximum des dirigeants (annees). Ex: 50 pour moins de 50 ans. Filtre si au moins un dirigeant correspond.
`appartient_groupe`	No	true = uniquement les societes appartenant a un groupe : filiales declarees OU soupcon de groupe fort (groupe_pont probable). Complement exact de independant_strict (ne pas envoyer les deux en meme temps).
`date_creation_min`	No	Date de creation minimum (ISO). Ex: "2021-01-01" pour les entreprises creees apres 2021
`groupe_pont_siren`	No	SIREN de la tete de groupe INFEREE (soupcon de groupe via dirigeant-pont). Retourne toutes les societes rattachees au meme groupe soupconne (non declare). A distinguer de siren_groupe (lien capitalistique declare).
`est_tete_de_groupe`	No	true = uniquement les tetes de groupe
`independant_strict`	No	true = uniquement les societes reellement independantes : exclut les filiales declarees ET les societes avec un soupcon de groupe fort (groupe_pont probable). Les soupcons plus faibles (possible/soupcon) ne sont pas exclus.
`dirigeant_naissance`	No	Naissance du dirigeant pour desambiguiser les homonymes, granularite mois : format YYYY-MM. Ex: "1975-03" (un YYYY-MM-DD est accepte mais le jour est ignore). Pour une desambiguisation au jour pres, utiliser search_director_companies.
`procedure_collective`	No	Procedure collective EN COURS (etat courant, pas l'historique). Valeurs: "liquidation", "redressement", "sauvegarde", "conciliation", "autre", "plan_redressement", "plan_sauvegarde", "plan_cession". Plusieurs separes par virgule. Une procedure cloturee ne matche pas : les societes dont la liquidation est close en sont exclues.
`societe_mere_etrangere`	No	true = filiales de groupes etrangers uniquement

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`url`	Yes
`name`	Yes
`filters`	No
`result_count`	Yes
`alert_enabled`	Yes
`already_exists`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations (idempotentHint=true), the description details the exact idempotent behavior: an existing active search with the same name is returned as-is with already_exists=true, no duplicate is created, and the existing alert is not modified. It also discloses the alert side effects: daily notifications, an initial 90-day recap, and only future matches triggering subsequent alerts.

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

Conciseness5/5

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

The description is well structured with a purpose statement, explicit usage guidance, a 'Fonctionnement' section, and a response summary. It is detailed enough for a 37-parameter tool but contains no filler; each section earns its place.

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 complex tool with rich schema and annotations, the description covers all necessary invocation context: when to use it, the idempotent behavior, alert consequences, the response shape including already_exists and result_count, and the post-creation action of sharing the URL with the user. Nothing an agent needs to call it correctly is missing.

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 97%, so the schema carries most parameter documentation. The description adds valuable high-level semantics by stating that accepted filters are the same as search_companies, listing the filter families, and emphasizing that at least one criterion is required—a constraint not obvious from the schema's required fields alone.

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 opens with a specific verb and resource: 'Creation d'une recherche sauvegardee pour l'utilisateur, visible dans l'app Insourcia (page /news - Veille).' It also distinguishes itself from search_companies, so an agent can tell exactly which tool creates persistent saved searches versus one-off company searches.

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?

The description explicitly states when to use the tool—'quand l'utilisateur veut SAUVEGARDER une recherche pour la suivre dans le temps'—and explicitly says not to use it for one-off searches, directing the agent to search_companies instead. It also notes the minimum criterion requirement.

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

All insourcia tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation4/5

Most tools have clearly distinct resource+action purposes, and the descriptions explicitly contrast near-neighbor tools like search_companies vs resolve_companies and get_events vs search_events. The only real risk is the trio of director-oriented tools, especially search_director_companies vs search_companies with dirigeant filters, which requires careful reading to avoid misselection.

Naming Consistency5/5

All 18 tools follow a consistent snake_case verb_noun pattern: search_, get_, list_, create_, watch_, unwatch_, mark_, resolve_. Singular names are used for single-entity actions and plural for list/search operations, making the pattern predictable. There is no camelCase, vague verb, or style mixing.

Tool Count4/5

18 tools is slightly above the ideal 10-15 range, but the count is justified by the broad domain covering search, company intelligence, watchlists, and news. Each tool appears to earn its place, and there are no obvious stubs or redundant duplicates. It feels a bit heavy but not bloated.

Completeness3/5

The company intelligence surface is very complete: search, deep company data, financials, directors, group graphs, events, and credit risk are all covered. Watchlists also have full add/remove/list coverage, but saved searches have a notable lifecycle gap—create and list exist, yet there is no update, delete, or alert-toggle for existing saved searches, creating a management dead end.

Resources

Need Help?