Skip to main content
Glama

insourcia

by io.insourcia
OverviewDiscussionsAdmin

get_news

Read-onlyIdempotent

Veille quotidienne de l'utilisateur : le fil d'actualite de ses societes surveillees, tel qu'il apparait sur la page /news de l'app Insourcia.

Utiliser cet outil pour repondre a "quoi de neuf sur ma veille ?", "qu'est-ce qui a bouge sur mes societes ?", "resume-moi ma veille de la semaine", ou avant de rediger un point hebdomadaire.

Contenu : les alertes reellement delivrees (email/push) ET l'activite des societes des listes de veille (changements de dirigeants, annonces BODACC : procedures collectives, cessions, radiations...), fusionnees et dedupliquees, les plus recentes d'abord. Couvre toutes les listes de l'utilisateur, tous espaces confondus (source.espace indique lequel).

Chaque ligne est HYBRIDE : "label" donne la phrase francaise prete a lire (identique a l'app) et "type"/"before"/"after"/"siren"/"date" donnent les champs structures pour filtrer ou raisonner. "date" est le jour de DETECTION (axe de fraicheur) ; "effective_date", quand present, est la date d'effet juridique.

unread_only=true ne renvoie que ce que l'utilisateur n'a pas encore lu.

"read_key" identifie chaque ligne : la passer a mark_news_read pour la marquer lue.

truncated=true signale plus de signaux que la limite demandee ; since_days et event_types permettent de resserrer (pas de pagination sur ce fil).

Si counts_are_partial=true, "total" et "unread_count" sont des PLANCHERS et non des totaux : le fil est compose sur une fenetre bornee (les 100 dernieres notifications et les 100 derniers evenements), et cette fenetre etait pleine.

hidden_by_plan, quand present, compte les signaux non retournes parce que le plan actuel ne donne acces qu'aux 10 signaux les plus recents, exactement comme la page /news. Un fil ainsi tronque n'est pas complet, et hidden_by_plan dit de combien.

Reponse : { news: [...], total, unread_count, last_seen_at, since_days, truncated, url (page /news) }. news vide = aucun signal sur la periode, ce n'est pas une erreur.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNombre max de signaux retournes (defaut 50, max 100)
since_daysNoProfondeur d'historique en jours (defaut 90, max 365)
event_typesNoFiltre sur les types d'evenements bruts. Ex: ["dirigeant_changed", "procedure_collective", "cession", "radiation"].
unread_onlyNotrue = uniquement les signaux non lus par l'utilisateur. Defaut : false.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
newsYes
totalYes
truncatedYes
since_daysYes
last_seen_atYes
unread_countYes
hidden_by_planNo
counts_are_partialNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • 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"
-]
  2. Changed3 schema fields changed
    • 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"
+]
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark it read-only/idempotent, and the description adds substantial behavior: merging and deduplication, ordering, detection date vs effective date, truncated flag, hidden_by_plan plan limits, partial counts as floors, and empty news as a valid result. No contradiction with annotations.

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 into labeled blocks that front-load purpose and usage before details. Every sentence carries operational information such as read_key, truncated, counts_are_partial, and hidden_by_plan, so the length is earned.

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?

Given the output schema exists and the tool has edge cases, the description is complete: it explains response fields, date semantics, plan truncation, empty results, and how to mark items read via mark_news_read. An agent has everything needed to call and interpret the tool correctly.

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; the description adds value by explaining how since_days and event_types tighten the feed, that there is no pagination, and that unread_only returns only unread items. This goes beyond the schema without needing to document each parameter from scratch.

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 opening sentence defines the tool as the user's daily watch feed for their monitored companies, as shown on the /news page, with a clear verb and resource. It further specifies the hybrid line structure and the merge of delivered alerts with company activity, making the tool's scope unmistakable and distinct from event/search siblings.

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?

The description gives explicit use cases ('Utiliser cet outil pour répondre à ...', 'ou avant de rédiger un point hebdomadaire'). It does not name alternative tools or state when not to use it, so it stops short of the top score.

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

All insourcia toolsInspect
Try in Browser
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