Skip to main content
Glama
Sign In

NeoDemos

by io.github.NeoDemosHQ
OverviewDiscussionsAdmin

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

NameRequiredDescriptionDefault
veldenNo
doc_typeYes
gemeenteNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / gemeente / default
      Previous value: -"rotterdam"New value: +null
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses no DB/network access and <10ms latency, the placeholder-filling behavior for missing velden, the gemeente-specific overlay mechanism with its 'rotterdam' default, and the graceful degradation to base format + disclaimer. Return content (markdown with RvO citation and disclaimer) is also stated.

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?

Front-loaded with the one-line purpose, then organized into scannable bullet blocks for when/when-not and parameter notes. Slightly long, but nearly every line carries decision-relevant information, so waste is minimal.

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?

With no output schema and no enum coverage, the description supplies the return format, the placeholder contract, the fallback behavior, defaults, and the recommended next steps. Nothing an agent needs to invoke it correctly is missing.

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% and doc_type has no enum in the schema, so the description is the only source of the seven valid doc_type values, which it lists in full. It also explains velden (optional, missing keys become placeholders) and gemeente (selects the RvO overlay, default 'rotterdam'), fully compensating for the schema gap.

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?

States a specific verb and resource ('Genereert een volledig opgemaakt, RvO-conformant concept voor één van de zeven raadsstuktypen') and scopes it precisely. It explicitly distinguishes itself from siblings advieser_raadsinstrument and beoordeel_tekst, so an agent can pick it without opening a schema.

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?

Provides an explicit 'Gebruik deze tool wanneer' block and a 'Gebruik deze tool NIET wanneer' block that names the exact alternative tool and condition for each exclusion. It even documents the ordered drafting chain (adviseer → genereer → beoordeel → sla op).

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
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