Skip to main content
Glama

NeoDemos

by io.github.NeoDemosHQ

get_neodemos_context

Retourneert een structured primer met de beschikbare gemeenten, document-types, de huidige zittende wethouders van Rotterdam (uit raadslid_rollen), de coalition-history per college-periode, known limitations, en recommended tool sequences voor veelvoorkomende vraagpatronen. Cheap to call (<50ms). Cached op server-niveau als de DB bereikbaar is.

Gebruik deze tool wanneer:

  • Je een nieuwe sessie start — dit geeft je de ground-truth voor rol/tenure/coalition in plaats van dat je uit trainingsdata moet gokken.

  • Je een actuele referentiedatum nodig hebt voor 'vandaag', 'recent', 'vorige week' of vergelijkbare temporele termen — het today veld wordt per call berekend.

  • De vraag gaat over een historische stemming — check coalition_history voor de compositie op dát moment (GroenLinks/PvdA waren in 2018 coalitiepartij, niet oppositie).

  • Je niet zeker weet welke tool sequence past — zie recommended_tool_sequences.

Gebruik deze tool NIET wanneer:

  • De vraag al duidelijk in één retrieval tool past en je de context al kent.

  • Je al in dezelfde sessie de context hebt opgehaald (het verandert niet binnen één sessie).

Retourneert: markdown met secties voor gemeenten, document-types, raadssamenstelling, college-history, limitations, en recommended tool-sequences.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full transparency burden. It discloses performance (<50ms), server-side caching, per-call calculation of the `today` field, and session-invariance. It also states the return format is markdown. However, it does not mention error behavior when the database is unreachable or any access restrictions, leaving a minor gap.

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 well-structured with a main purpose, bullet-pointed usage scenarios, and a return format summary. It is front-loaded with the core purpose and performance. While it is longer than necessary, every sentence provides actionable guidance and no filler, earning a 4 rather than a 5.

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 context-primer tool with no parameters and no output schema, the description is remarkably complete. It details the exact sections returned, explains the `today` field, gives historical examples, mentions known limitations, and directs users to recommended tool sequences. This leaves little ambiguity about when and how to use the tool.

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?

The tool has zero parameters, and the schema reflects that with no properties. The baseline for 0-parameter tools is 4, and the description appropriately clarifies that it takes no inputs and instead focuses on the contextual value it provides. No additional parameter semantics are needed.

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 explicitly states it returns a structured primer containing municipalities, document types, current aldermen, coalition history, limitations, and recommended tool sequences. This goes far beyond a simple verb+resource, providing a detailed inventory of the tool's output. It clearly distinguishes itself from siblings like verzamel_context by framing itself as a session-start primer.

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 provides dedicated 'Gebruik deze tool wanneer' and 'Gebruik deze tool NIET wanneer' sections with concrete conditions, such as starting a new session, needing a current date, handling historical votes, and avoiding redundant calls. It also references alternative tool sequences, making the usage context explicit.

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

All NeoDemos toolsInspect
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.4/5.0
Disambiguation4/5

Each tool has a distinct primary function: advising on instruments, reviewing text, formatting citations, generating a memo, generating a council document, retrieving context, and gathering background data. However, adviseer_raadsinstrument and verzamel_context's instrument_doel option overlap in providing instrument advice, which could lead to misselection.

Naming Consistency4/5

Names follow a consistent verb_noun pattern in Dutch (adviseer_, beoordeel_, formatteer_, genereer_, verzamel_), with one deviation: get_neodemos_context uses the English verb 'get' instead of the Dutch imperative, breaking the pattern slightly.

Tool Count5/5

Seven tools is well within the ideal 3-15 range and each tool serves a clear purpose in the council-member workflow, from advising and generating documents to reviewing and gathering context. No tool feels redundant or out of place.

Completeness2/5

The set covers drafting and reviewing but references essential missing tools (zoek_raadshistorie, zoek_moties, lijst_vergaderingen, mijn_fractie_context, sla_fractie_artifact_op). This creates dead ends, such as genereer_fractienotitie requiring meeting_ids from a tool that is not available, and no way to search existing documents or save generated artifacts.

Resources