insourcia

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 : c'est le mode a privilegier pour un point quotidien.

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

Si truncated=true, il y a plus de signaux que la limite demandee : reduire since_days ou filtrer avec event_types (il n'y a 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. Ne pas annoncer ces nombres comme exhaustifs a l'utilisateur.

hidden_by_plan, quand present, compte les signaux non retournes parce que le plan Free est limite a 5 par jour (meme plafond que la page /news, le digest email et le flux RSS).

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

Name	Required	Description
`limit`	No	Nombre max de signaux retournes (defaut 50, max 100)
`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."
`since_days`	No	Profondeur d'historique en jours (defaut 90, max 365)
`event_types`	No	Filtre sur les types d'evenements bruts. Ex: ["dirigeant_changed", "procedure_collective", "cession", "radiation"].
`unread_only`	No	true = uniquement les signaux non lus par l'utilisateur. Defaut : false.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`news`	Yes
`total`	Yes
`truncated`	Yes
`since_days`	Yes
`last_seen_at`	Yes
`unread_count`	Yes
`hidden_by_plan`	No
`counts_are_partial`	No

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral detail: merged/deduplicated content, date detection vs effective date, no pagination, truncated behavior, counts_are_partial semantics, hidden_by_plan limits, and the meaning of an empty news array. 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.

Conciseness4/5

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

The description is long but well organized: purpose, trigger questions, content composition, per-line fields, filtering flags, plan limitations, and response shape. It is front-loaded and dense, though it could be slightly trimmed without losing value, so it does not reach a perfect score.

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?

The description is remarkably complete for the tool's complexity. It explains the hybrid output structure, freshness semantics, how to mark items as read via read_key, the absence of pagination, partial count warnings, plan caps, and the exact response shape. An agent has enough context to invoke this tool and interpret its results 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 practical meaning beyond the schema: unread_only is the preferred mode for daily points, truncated=true should trigger reducing since_days or filtering with event_types, and the limit context is reinforced. This goes beyond mere repetition of schema definitions.

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

Purpose4/5

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

The description clearly identifies the resource: the user's daily news feed of watched companies as shown on the /news page of Insourcia. It conveys the specific purpose and content composition, but it does not explicitly name sibling tools like get_events or search_events to draw a contrast.

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 explicitly lists trigger questions ('quoi de neuf sur ma veille ?', 'résume-moi ma veille de la semaine') and says it should be used before writing a weekly summary. It also recommends unread_only=true for daily briefings, but it does not state when to prefer alternative tools such as get_events.

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?