uk-parliament-mcp-server

Ukparl Get Member

ukparl_get_member

Read-onlyIdempotent

Retrieve a member profile, roles, committee seats, official contact information, registered interests or recorded voting history. Roles without category lists available biography categories; select category to page whole periods. Interests and voting require an explicit House. Committee person IDs differ from member IDs. Voting uses native 20-row pages and reports recorded lobby and teller facts, without lifetime participation metrics. Follow collection cursors with unchanged selectors; use contentCursor to reconstruct oversized records.

Input Schema

Name	Required	Description	Default
`house`	No	Required for interests and voting; forbidden for other sections.
`limit`	No	Requested whole rows; default 20, cap 50 for local histories. Voting uses native 20-row pages independently of limit.
`cursor`	No	Opaque whole-item collection continuation with unchanged selectors.
`section`	No	Selected member subsection; default profile.	profile
`category`	No	Roles only: select one complete biography collection.
`memberId`	Yes	Members API decimal identifier from ukparl_search_members.
`contentCursor`	No	Opaque same-selection lossless content continuation.

Output Schema

Name	Required	Description
`cap`	No	Effective whole-item workload cap.
`page`	No	Continuation by actual emitted items.
`error`	No	Present when the call failed. Absent on success.
`found`	No	Whether the parent member exists.
`items`	No	Whole selected source records tagged by kind.
`links`	No	Selected source relationship links.
`shown`	No	Actual whole items emitted in this collection page.
`notice`	No	Licence, coverage and workload notices.
`record`	No	Whole member profile or explicit role category outline.
`source`	No	Actual selected source request.
`applied`	No	Normalized selectors, source and effective workload.
`section`	No	Selected member subsection.
`delivery`	No	Full selected payload, child outline, or JSON fragment.
`guidance`	No	Absence, uncertainty or same-server follow-up guidance.
`identity`	No	Stable selected-record identifiers retained during content retrieval.
`memberId`	No	Canonical Members API identifier.
`retrieval`	No	Same-tool retrieval instruction.
`truncated`	No	Further whole collection items remain.
`nativePage`	No	Actual requested source voting page, starting at one.
`provenance`	No	Selected response provenance retained during content retrieval; source notices remain in the reconstructed payload.
`totalCount`	No	Complete selected collection count when known.
`contentPage`	No	Lossless recursive content continuation.
`collectionPage`	No	Collection continuation; reconstruct the outlined selected payload before following it.
`nativePageSize`	No	Native voting page size, independent of caller limit.
`requestedLimit`	No	Caller limit when a cap or native-page rule applies.
`membershipContexts`	No	Source person metadata, including people with unavailable or empty membership collections.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses important behavior: voting uses native 20-row pages, reports lobby and teller facts, and omits lifetime participation metrics. It also explains cursor continuation rules and the existence of contentCursor for reconstructing oversized records.

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 dense but front-loaded and every clause carries operational meaning. It is somewhat semicolon-heavy and could be easier to scan, but it does not waste words.

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 seven-parameter tool with an output schema and rich annotations, the description covers all critical caller decisions: section selection, house applicability, role categories, cursor handling, and voting pagination. Nothing essential is missing for correct 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?

Although schema coverage is already 100%, the description adds cross-parameter semantics: house is required for interests/voting, category applies only to roles, and cursor continuation requires unchanged selectors. It also clarifies that voting pagination is independent of the limit parameter and that committee person IDs differ from member IDs.

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 gives a specific verb and resource: retrieving a member profile and its subsections (roles, committee seats, contact, interests, voting). It clearly distinguishes the tool from list/search siblings by requiring a member ID and by enumerating member-specific subsections.

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?

It gives clear usage conditions: interests and voting require an explicit House, and roles need a category to page whole biography collections. It does not explicitly mention when to use this instead of ukparl_search_members, but the get-vs-search distinction is clear from the description.

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

All uk-parliament-mcp-server tools Inspect

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.