Skip to main content
Glama

NeoDemos

by io.github.NeoDemosHQ

genereer_raadsstuk

Read-onlyIdempotent

Genereert een volledig opgemaakt, RvO-conformant concept voor één van de zeven raadsstuk­typen. Geen DB, geen netwerk, <10ms — puur structurele kennis.

Gebruik deze tool wanneer:

  • Het raadslid een stuk wil indienen en een correct gestructureerd concept nodig heeft.

  • Je adviseer_raadsinstrument hebt gebruikt (welk instrument) en nu het daadwerkelijke stuk wilt renderen in het juiste format met RvO-verwijzingen.

  • Een concept al bestaat maar opnieuw in correct format moet worden gezet.

Gebruik deze tool NIET wanneer:

  • Je het juiste instrument nog moet kiezen → gebruik eerst adviseer_raadsinstrument.

  • Je een bestaand concept wilt beoordelen op inhoud → beoordeel_tekst.

  • Je een format-validatie wil uitvoeren op een bestaand concept → beoordeel_tekst met soort gelijk aan het doc_type.

doc_type keuzes: 'motie', 'motie_vreemd', 'amendement', 'schriftelijke_vragen', 'mondelinge_vragen', 'initiatiefvoorstel', 'interpellatieverzoek'.

velden zijn optioneel — ontbrekende velden worden vervangen door invul-placeholders [zoals dit] zodat het concept altijd een compleet, geldig skelet is.

gemeente bepaalt welk lokaal RvO-overlay (artikel­nummers, termijnen, indienings­route) wordt gebruikt. Default 'rotterdam'. Degradeert netjes naar het canonieke basis­format + disclaimer als er geen overlay beschikbaar is.

Retourneert: markdown-concept in de juiste RvO-structuur, met RvO-artikel­citaat en disclaimer.

Volgende stap in de drafting-keten: valideer het gegenereerde concept met beoordeel_tekst(tekst=<concept>, soort=<doc_type>) voordat je het presenteert of opslaat; sla daarna op met sla_fractie_artifact_op(artifact_type=<doc_type>).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
veldenNo
doc_typeYes
gemeenteNorotterdam

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark readOnly/idempotent/non-destructive; the description adds valuable beyond-annotation context: no DB/network, <10ms performance, placeholders for missing fields, graceful degradation to a base format + disclaimer when no gemeente overlay exists, and return type (markdown with RvO citation and disclaimer). This aligns with annotations and enriches them, so no contradiction.

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 and front-loaded: it opens with a one-sentence summary, then uses clear 'when/when-not' subheadings, followed by concise parameter explanations and a return value note. Every sentence adds necessary guidance for a 3-parameter, 7-type tool; no repetition of schema information or filler.

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 tool with no output schema and moderate complexity, the description fully covers purpose, selection criteria, parameter semantics, return value, and next-step integration into the drafting pipeline. It also clarifies edge cases (missing fields, missing overlay) and names sibling tools for disambiguation, making the description self-sufficient for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully compensates: doc_type is explained with the seven allowed values, velden is described as optional and automatically filled with placeholders, and gemeente is clarified with its default ('rotterdam') and fallback behavior. This goes beyond the schema's bare type/required/default fields, giving an agent everything needed to construct valid inputs.

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 ('Genereert') and resource ('volledig opgemaakt, RvO-conformant concept voor één van de zeven raadsstuktypen'), clearly distinguishing this generation tool from siblings like adviseer_raadsinstrument (choosing instrument) and beoordeel_tekst (evaluation). It even names the seven doc_type values, making scope explicit.

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 explicit 'Gebruik deze tool wanneer' and 'Gebruik deze tool NIET wanneer' sections, citing exact alternative tools (adviseer_raadsinstrument, beoordeel_tekst) and conditions. It closes with a recommended next-step workflow (validate with beoordeel_tekst, then save with sla_fractie_artifact_op), making usage decisively clear.

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