Skip to main content

insourcia

by io.insourcia

Overview Discussions Admin

search_events

Read-onlyIdempotent

Recherche unifiee d'evenements d'entreprise (cross-SIREN), basee sur notre index ES.

Renvoie des EVENEMENTS individuels (pas des entreprises) : { date, type, siren, denomination, data }. Couvre 8 types : cession (cessions de fonds), procedure (procedures collectives), depot_comptes, augmentation_capital, marche_public, subvention, radiation, creation.

Couvre les evenements BODACC (cessions, procedures collectives, radiations, creations) ainsi que les depots de comptes, augmentations de capital, marches publics et subventions derives des scalaires silver.

REGLE : preciser au moins un filtre region / departement / ville / code_naf, OU un filtre d'evenement (date_min, date_max, cedant_siren, cessionnaire_siren, prix_min/max, tribunal, procedure_type) — sinon 400.

IMPORTANT : passer UN SEUL type quand la question porte sur un type precis. Les filtres de cadrage (existence de l'evenement, fenetre de dates) ne sont pousses dans la requete que dans ce cas ; avec plusieurs types ils s'excluraient mutuellement, et la recherche se rabat sur un tri general dont on ne lit que les premieres pages — une question pointue y parait vide.

Cas d'usage :

"Cessions de fonds > 1M en Ile-de-France depuis 2024" → type="cession", region="Ile-de-France", date_min="2024-01-01", prix_min=1000000
"Procedures collectives a Lyon" → type="procedure", ville="Lyon"
"Liquidations prononcees a Marseille en juillet 2026" → type="procedure", procedure_type="liquidation", ville="Marseille", date_min="2026-07-01", date_max="2026-07-31"
"Marches publics recents dans le BTP" → type="marche_public", code_naf="4120A"

Input Schema

TableJSON Schema

Name	Required	Description	Default
`type`	No	Types d'evenements (CSV) : cession, procedure, depot_comptes, augmentation_capital, marche_public, subvention, radiation, creation. Defaut : tous.
`limit`	No	Nombre d'evenements (defaut 50, max 200)
`ville`	No	Ville du siege (CSV possible). Ex: "Marseille". Le bon filtre pour un ressort de tribunal : plus etroit que departement.
`cursor`	No	Curseur de pagination (plan Pro uniquement)
`region`	No	Region. Ex: "Ile-de-France", "Bretagne"
`code_naf`	No	Code NAF/APE (CSV possible)
`date_max`	No	Date max (YYYY-MM-DD)
`date_min`	No	Date min (YYYY-MM-DD)
`prix_max`	No	Prix de vente max en euros (filtre cession)
`prix_min`	No	Prix de vente min en euros (filtre cession)
`tribunal`	No	Tribunal (filtre procedure, recherche partielle)
`departement`	No	Code departement. Ex: "75", "69"
`cedant_siren`	No	SIREN du cedant (filtre cession)
`procedure_type`	No	Type(s) de procedure (CSV) : liquidation, redressement, sauvegarde, conciliation
`cessionnaire_siren`	No	SIREN du cessionnaire (filtre cession)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`pagination`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 22, 2026

addedInput schema / properties / ville

Added value: +{
+  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
+  "type": "string"
+}

Changed1 schema field changedSep 22, 2026

removedInput schema / properties / ville

Removed value: -{
-  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
-  "type": "string"
-}

Changed1 schema field changedSep 22, 2026

addedInput schema / properties / ville

Added value: +{
+  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
+  "type": "string"
+}

Changed1 schema field changedSep 22, 2026

removedInput schema / properties / ville

Removed value: -{
-  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
-  "type": "string"
-}

Changed1 schema field changedSep 22, 2026

addedInput schema / properties / ville

Added value: +{
+  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
+  "type": "string"
+}

Changed1 schema field changedSep 22, 2026

removedInput schema / properties / ville

Removed value: -{
-  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
-  "type": "string"
-}

Changed1 schema field changedSep 22, 2026

addedInput schema / properties / ville

Added value: +{
+  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
+  "type": "string"
+}

Changed1 schema field changedSep 22, 2026

removedInput schema / properties / ville

Removed value: -{
-  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
-  "type": "string"
-}

Changed1 schema field changedSep 22, 2026

addedInput schema / properties / ville

Added value: +{
+  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
+  "type": "string"
+}

Changed1 schema field changedSep 22, 2026

removedInput schema / properties / ville

Removed value: -{
-  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
-  "type": "string"
-}

Changed1 schema field changedSep 22, 2026

addedInput schema / properties / ville

Added value: +{
+  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
+  "type": "string"
+}

Changed1 schema field changedSep 22, 2026

removedInput schema / properties / ville

Removed value: -{
-  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
-  "type": "string"
-}

Changed1 schema field changedSep 18, 2026

addedInput schema / properties / ville

Added value: +{
+  "description": "Ville du siege (CSV possible). Ex: \"Marseille\". Le bon filtre pour un ressort de tribunal : plus etroit que departement.",
+  "type": "string"
+}

Changed3 schema fields changedSep 3, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / context

Removed value: -{
-  "description": "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.\"",
-  "type": "string"
-}

removedInput schema / required
```
Removed value: -[
-  "context"
-]
```

Changed3 schema fields changedSep 1, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / context

Added value: +{
+  "description": "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.\"",
+  "type": "string"
+}

addedInput schema / required
```
Added value: +[
+  "context"
+]
```

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses the underlying ES index, the multi-source coverage (BODACC + scalars silver), and a non-obvious pitfall: multiple types cause filters to exclude each other and fall back to a shallow first-page sort. It also specifies the required filter condition, giving agents realistic expectations about failures.

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 long but organized with bold labels (REGLE, IMPORTANT, Cas d'usage) and front-loads purpose and return type before caveats. Each section adds distinct information, and the examples are terse and directly map to parameter values. This is structured efficiency, not bloat.

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 15-parameter search tool with no required params, the mandatory-filter rule is critical and present, as are the result shape, covered types, and failure behavior. The existence of an output schema covers return details, so the description doesn't need more; only minor details like sort order are omitted, but the caveat already hints at it.

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 baseline is 3, but the description adds crucial cross-parameter constraints (at least one geographic/NAF filter or one event filter), maps filters to event types (prix* for cessions, procedure_type/tribunal for procedures), and provides concrete value examples. This lifts it above the schema-only baseline, though not all 15 params get equal treatment.

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 ('Recherche unifiee') and resource ('evenements d'entreprise'), explicitly distinguishes the return shape ('EVENEMENTS individuels (pas des entreprises)') and enumerates the 8 covered event types. This clearly separates the tool from company-level searches and from sibling get_events/search_companies without ambiguity.

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?

It gives an explicit mandatory-filter rule with the exact list of acceptable filters and the 400-error consequence, plus an IMPORTANT warning about passing only one type and why. Four concrete natural-language-to-parameter examples illustrate when and how to use the tool. It does not name sibling alternatives explicitly, but the context is strong enough to compensate.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?