Skip to main content
Glama
dragosh29

Citizen Space MCP server

by dragosh29
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Search public activities

search_public_activities
Read-only

Search public Citizen Space consultations and activities by text, postcode, state, audience, interest, department, area, date, and type.

Instructions

Published, public consultations and other activities on the site, from the unauthenticated Public API (json_search_results). Every documented search argument is passed through: free text, postcode, state, audience, interest, department, area, a date range on the open or close date, activity type. fields=basic gives id, title, url, status, overview and dates; extended adds department, type and participation URL; all adds the 'why' and 'what happens next' text, contact details, related links, documents, audiences, areas and interests. Officer contact phone and email are only returned with include_contact_details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoFree text search on title and overview, case-insensitive (argument tx)
stateNoopen, forthcoming or closed (argument st)
fieldsNoWhich groups of fields to returnbasic
area_idNoOne of the area IDs configured on the site (argument ar)
date_toNoEnd of the date range, yyyy/mm/dd (argument td)
postcodeNoPostcode, partial allowed, e.g. BS8 (argument pc)
date_fromNoStart of the date range, yyyy/mm/dd (argument fd)
date_kindNoWhich date the range applies to: op (open date) or cl (close date); required with date_from/date_to (argument dk)
audience_idNoOne of the audience IDs configured on the site (argument au)
interest_idNoOne of the interest IDs configured on the site (argument in)
max_resultsNoThe API returns every match in one response; only the first max_results are shown
activity_typeNoQuickConsult (online survey), File (email/postal), Document (offline) or Link (argument ct)
department_idNoThe ID of the department the activity sits within (argument de)
include_contact_detailsNoInclude the activity's contact phone and email (fields=all) and stop redacting emails, phone numbers and postcodes from text

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations by disclosing the field-tier behavior (basic vs extended vs all and exactly what each adds), the redaction behavior tied to include_contact_details ('stop redacting emails, phone numbers and postcodes from text'), and that officer contact details are gated on that flag.

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?

A single dense paragraph that front-loads the purpose before the argument list; every clause carries information, though it reads as a wall of text and would scan better as bullets.

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 14 parameters, no output schema, and no annotations covering returns, the description fills the gap by describing what each argument does and what the three field tiers actually return — enough for an agent to call it 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, but the description earns more by explaining the otherwise thin 'fields' enum ('Which groups of fields to return') in concrete terms and clarifying the relationship between include_contact_details, fields=all, and text redaction.

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?

Names a specific verb+resource (search public activities/consultations) and scopes it precisely: 'Published, public consultations and other activities on the site, from the unauthenticated Public API'. An agent can distinguish it from get_public_activity by the plural/search framing, but the description never explicitly contrasts the two siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied through the enumeration of supported search arguments (free text, postcode, state, etc.) and the note that it uses the unauthenticated Public API, but there is no explicit 'use this when you want to search vs. use get_public_activity when you have an id' guidance or any exclusions.

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

Deploy Server

Other Tools