How do I use NSW Parliament Hansard MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NSW Parliament Hansard MCP Server search for speeches by Chris Minns" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

NSW Parliament Hansard MCP Server

by lawquarter

Overview Schema Related Servers Score Discussions

JavaScript

Remote

NSW Parliament Hansard MCP Server

A Model Context Protocol (MCP) server that provides programmatic access to the New South Wales Parliament Hansard API. This server enables AI assistants and applications to search, retrieve, and analyse parliamentary transcripts, debates, and proceedings from September 1991 to the present day.

Related MCP server: Taiwan Legislative Yuan MCP Server

Features

Comprehensive Hansard Access: Search and retrieve parliamentary transcripts from both the Legislative Assembly (Lower House) and Legislative Council (Upper House)
Multiple Search Methods: Search by year, date, speaker name, or bill name
Multiple Output Formats: Access data in JSON, XML, or PDF formats
Table of Contents: Retrieve structured tables of contents for any sitting day
Speaker Search: Find speeches by specific members with wildcard support
Bill Tracking: Search for all debates and mentions related to specific legislation
Historical Data: Access records dating back to September 1991
No Authentication Required: Free public access to all endpoints

Installation

Prerequisites

Node.js 18.0.0 or higher
npm or yarn package manager

Install from npm

npm install -g nsw-hansard-mcp

Install from Source

git clone https://github.com/lawquarter/nsw-hansard-mcp.git
cd nsw-hansard-mcp
npm install
npm run build

Configuration

Claude Desktop

Add the following to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "nsw-hansard": {
      "command": "npx",
      "args": ["-y", "nsw-hansard-mcp"]
    }
  }
}

Claude Code

Add to your Claude Code MCP settings:

{
  "mcpServers": {
    "nsw-hansard": {
      "command": "npx",
      "args": ["-y", "nsw-hansard-mcp"]
    }
  }
}

Local Development

If running from source:

{
  "mcpServers": {
    "nsw-hansard": {
      "command": "node",
      "args": ["/path/to/nsw-hansard-mcp/dist/index.js"]
    }
  }
}

Available Tools

hansard_search_by_year

Search all Hansard records for a specific year.

Parameters:

Parameter	Type	Required	Description
`year`	integer	Yes	The year to search (1991 or later)

Example:

{
  "year": 2024
}

hansard_search_by_date

Get detailed Hansard information for a specific date.

Parameters:

Parameter	Type	Required	Description
`date`	string	Yes	Date in YYYY-MM-DD format

Example:

{
  "date": "2024-03-15"
}

hansard_get_fragment_xml

Retrieve the raw XML content of a specific Hansard fragment.

Parameters:

Parameter	Type	Required	Description
`documentId`	string	Yes	Unique document identifier

hansard_get_fragment_html

Retrieve a Hansard fragment as JSON with HTML content.

Parameters:

Parameter	Type	Required	Description
`documentId`	string	Yes	Unique document identifier

hansard_get_pdf_url

Get the URL for downloading a Hansard PDF (post-1991 documents).

Parameters:

Parameter	Type	Required	Description
`documentId`	string	Yes	Unique document identifier

hansard_get_searchable_pdf_url

Get the URL for a searchable Hansard PDF (pre-1991 historical documents).

Parameters:

Parameter	Type	Required	Description
`documentId`	string	Yes	Unique document identifier

hansard_get_table_of_contents_xml

Retrieve the table of contents for a sitting day in XML format.

Parameters:

Parameter	Type	Required	Description
`documentId`	string	Yes	Unique document identifier

hansard_get_table_of_contents_json

Retrieve the table of contents as structured JSON.

Parameters:

Parameter	Type	Required	Description
`documentId`	string	Yes	Unique document identifier

hansard_search_by_speaker

Search Hansard records by speaker name with optional filters.

Parameters:

Parameter	Type	Required	Description
`speakerName`	string	Yes	Speaker name (supports wildcards: `*`)
`parliamentSessionId`	integer	No	Limit to specific parliament session
`startDate`	string	No	Start date in YYYY/MM/DD format
`endDate`	string	No	End date in YYYY/MM/DD format
`houseCode`	string	No	`LH` (Lower House) or `UH` (Upper House)
`memberId`	integer	No	Unique member identifier
`rowLimit`	integer	No	Maximum results (default: 100)

Example:

{
  "speakerName": "Smith*",
  "startDate": "2024/01/01",
  "endDate": "2024/12/31",
  "houseCode": "LH"
}

hansard_search_by_bill

Search Hansard records by bill name.

Parameters:

Parameter	Type	Required	Description
`billName`	string	Yes	Name of the bill (partial matching supported)

Example:

{
  "billName": "Environmental Planning"
}

hansard_list_sitting_dates

List all parliamentary sitting dates.

Parameters: None

hansard_list_sitting_date_types

List all types of sitting dates.

Parameters: None

Available Resources

hansard://info

Information about the NSW Parliament Hansard API, including coverage dates, available data, and usage notes.

hansard://terms

Usage Examples

Searching for Recent Debates

To find all Hansard records from 2024:

Use hansard_search_by_year with year: 2024

Finding a Specific Day's Proceedings

To get the Hansard for a specific sitting day:

Use hansard_search_by_date with date: "2024-03-15"

Searching by Member

To find speeches by a specific member:

Use hansard_search_by_speaker with:
- speakerName: "Jones*"
- startDate: "2024/01/01"
- endDate: "2024/06/30"
- houseCode: "LH"

Tracking Legislation

To find all debates about a specific bill:

Use hansard_search_by_bill with billName: "Housing Amendment"

API Reference

This MCP server interfaces with the NSW Parliament Hansard API:

Base URL: https://api.parliament.nsw.gov.au/api

Endpoints Used

Endpoint	Method	Description
`/hansard/search/year/{year}`	GET	Search by year
`/hansard/search/bydate`	GET	Search by date
`/hansard/search/daily/fragment/{documentId}`	GET	Get XML fragment
`/hansard/search/daily/fragment/html/{documentId}`	POST	Get HTML fragment
`/hansard/search/daily/pdf/{documentId}`	GET	Get PDF
`/hansard/search/daily/searchablepdf/{documentId}`	GET	Get searchable PDF
`/hansard/search/daily/tableofcontents/{documentId}`	GET	Get TOC XML
`/hansard/search/daily/tableofcontentsbydate/{documentId}`	POST	Get TOC JSON
`/hansard/search/byspeaker`	GET	Search by speaker
`/hansard/search/daily/bybill`	GET	Search by bill
`/sittingdate`	GET	List sitting dates
`/sittingdatetype`	GET	List sitting date types

For complete API documentation, visit:

Data Coverage

Temporal Coverage

Start Date: September 1991
End Date: Present (updated regularly)

Content Types

Daily transcripts (corrected and uncorrected)
Table of contents
PDF documents
Speaker records
Bill debates

Chambers

Legislative Assembly (LH): The Lower House of NSW Parliament
Legislative Council (UH): The Upper House of NSW Parliament

Terms of Use

NSW Parliament Copyright Notice

The material provided through this MCP server originates from the NSW Parliament Hansard API and is subject to copyright under the Copyright Act 1968 (Cth). Copyright is owned by the State of New South Wales through the Parliament of New South Wales.

Permitted Use

The Parliament of NSW encourages the availability, dissemination and exchange of public information. You may copy, distribute, display, download and otherwise deal with the material on the following conditions:

Non-commercial purposes: Use must not be for advertising, satire, or ridicule
No misrepresentation: Use must not misrepresent members of Parliament
Attribution required: You must include the copyright notice:
© State of New South Wales through the Parliament of New South Wales

Restrictions

This permission does not extend to copyright in materials owned by others, such as papers tabled in Parliament
Evidence, submissions and other material provided to committees should not be re-published or distributed without first being authorised by the relevant committee or House
Use of the Parliamentary Crest is permitted only where reproduction is incidental to use of publications in accordance with the copyright notice
The Parliament does not authorise any other use or reproduction of the Parliamentary Crest and other parliamentary symbols and logos without prior written permission
Copyright of broadcast material belongs to NSW Parliament and no unauthorised use may be made of that material

Disclaimer

The Hansard API is provided on an "as is" basis
The Parliament of NSW is not liable for loss or damage arising from use of the material or from delays or interruptions in service
The Parliament does not provide developers with any direct support for API usage beyond the available documentation

Full Terms

For the complete terms and conditions, please visit: NSW Parliament Copyright & Conditions of Use

License

This MCP server implementation is released under the MIT License.

MIT License

Copyright (c) 2025 Law Quarter

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Important: While this software implementation is MIT licensed, the data obtained through the NSW Parliament Hansard API is subject to the NSW Parliament's copyright and conditions of use as described in the Terms of Use section above.

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request

Support

This MCP server is maintained by Law Quarter.

For issues related to this MCP server implementation, please open an issue on GitHub.

Note: The NSW Parliament does not provide direct support for API usage. For API-related queries, refer to the official documentation links provided above.

Acknowledgements

NSW Parliament for providing the Hansard API
Model Context Protocol for the MCP specification
Data.NSW for API documentation and data hosting

Disclaimer: This project is not officially affiliated with or endorsed by the NSW Parliament. It is an independent implementation that interfaces with the publicly available Hansard API.

Available Tools

12 tools

hansard_get_fragment_htmlB

Retrieve a Hansard fragment as a JSON payload with HTML content. More readable format for display purposes.

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes	The unique document ID for the Hansard fragment

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided; description only states return format (JSON with HTML). Does not disclose authentication, side effects, rate limits, or pagination behavior.

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?

Two sentences, no redundant words, action verb upfront, perfect structure for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple tool with one parameter and no output schema, but lacks details on HTML content structure, error handling, or typical use cases.

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

Parameters3/5

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

Schema coverage is 100% and description adds no extra meaning beyond 'unique document ID'. Baseline score of 3 applies as description does not enhance parameter understanding.

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?

Description clearly states verb 'Retrieve', resource 'Hansard fragment', and format 'JSON payload with HTML content'. It distinguishes from siblings like hansard_get_fragment_xml by emphasizing human-readable display purpose.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool over alternatives. Only implies display use but does not mention when to choose HTML over XML or PDF formats.

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

hansard_get_fragment_xmlA

Retrieve the raw XML content of a specific Hansard fragment/document. Useful for detailed processing of parliamentary proceedings.

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes	The unique document ID for the Hansard fragment

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states 'Retrieve', implying a read operation, but does not disclose any behavioral traits like idempotency, side effects, or authentication needs.

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?

Two sentences, no extraneous information. Efficiently front-loaded with the action and use case.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter retrieval tool, the description is fairly complete. It states the output is raw XML, which is sufficient given no output schema. However, it could mention that it is read-only.

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

Parameters3/5

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

Schema description coverage is 100% with a clear description of documentId. The tool's description adds no additional meaning beyond the schema.

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 clearly states the verb 'Retrieve' and the resource 'raw XML content of a specific Hansard fragment'. It distinguishes from siblings like hansard_get_fragment_html by specifying the XML format.

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?

The description says 'Useful for detailed processing', which implies a use case but does not explicitly state when not to use it or mention alternatives. No exclusions are provided.

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

hansard_get_pdf_urlB

Get the URL for downloading the PDF version of a Hansard document (post-1991 documents).

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes	The unique document ID for the Hansard PDF

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It only states it returns a URL, but does not disclose whether authentication is needed, if the PDF might not exist, or any side effects. Minimal behavioral context.

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?

Single sentence, no wasted words. However, it could include more detail without being verbose. Good front-loading of purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with 1 parameter and no output schema, the description is minimally adequate. It specifies the document type and time constraint, but lacks mention of output format, error handling, or how to obtain document IDs from sibling tools.

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

Parameters3/5

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

Schema coverage is 100%, so the description adds no extra meaning beyond 'documentId' description. Baseline of 3 is appropriate as no additional semantics provided.

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 clearly states the verb 'get', the resource 'URL for downloading PDF', and the constraint 'post-1991 documents'. It effectively distinguishes from sibling tools like hansard_get_fragment_xml.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives. The description only mentions a time constraint but lacks context about prerequisites (e.g., needing a document ID from search) or when not to use it.

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

hansard_get_searchable_pdf_urlC

Get the URL for downloading the searchable PDF version of a Hansard document (pre-1991 historical documents).

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes	The unique document ID for the searchable PDF

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully inform behavior. It only notes the document type limitation (pre-1991) but does not disclose important traits like authentication needs, URL expiration, or if the URL is directly downloadable.

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?

Single sentence, front-loaded with the core purpose. Efficient and to the point, but could optionally include more detail without becoming overly long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description adequately conveys the basic purpose and document type restriction. However, it lacks details about the nature of the returned URL (e.g., direct download or not), which would improve completeness.

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

Parameters3/5

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

Schema coverage is high (100% with description for the one parameter). The description adds no extra meaning beyond the schema's 'unique document ID for the searchable PDF', so the baseline score of 3 is appropriate.

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?

Description specifies the action (Get the URL), resource (searchable PDF version), and context (pre-1991 historical documents). It is clear and distinct from sibling tools like hansard_get_pdf_url, though the distinction is implicit.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as hansard_get_pdf_url. The user is left to infer the difference based on the description's mention of 'searchable PDF' and 'pre-1991'.

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

hansard_get_table_of_contents_jsonB

Retrieve the table of contents for a specific Hansard day as a structured JSON payload.

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes	The unique document ID for the table of contents

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states a basic read operation without disclosing any behavioral traits such as error handling, authentication needs, or rate limits. This is minimal transparency for a tool with no structured safety hints.

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 a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and output format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is adequate but lacks details on the output structure or error states. For a minimal tool, this is acceptable but not thorough.

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

Parameters3/5

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

Schema description coverage is 100%, and the description does not add additional meaning beyond the schema's description of 'documentId' as 'The unique document ID for the table of contents'. Baseline score of 3 is appropriate since the description adds no extra value.

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 uses the specific verb 'Retrieve' and identifies the resource as 'table of contents for a specific Hansard day' with output format 'structured JSON payload'. It clearly distinguishes from the sibling tool 'hansard_get_table_of_contents_xml' which returns XML.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its alternatives (e.g., when to choose JSON over XML, or prerequisites for the documentId). Without explicit usage context, an agent may not select the correct tool for the format needed.

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

hansard_get_table_of_contents_xmlA

Retrieve the table of contents for a specific Hansard day in raw XML format.

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes	The unique document ID for the table of contents

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It correctly indicates a read operation ('Retrieve'), but does not disclose any potential side effects, rate limits, or output structure. For a simple retrieval tool, this is adequate but minimal.

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 a single 13-word sentence that front-loads the purpose. Every word is necessary; no waste. It is appropriately sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description mentions 'raw XML format' which is valuable. For a one-parameter read tool, it covers the main purpose. Could mention that the output is the raw XML content directly, but it's nearly complete.

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

Parameters3/5

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

Schema coverage is 100% for the single parameter 'documentId', and its schema description clearly states its purpose. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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 clearly states the verb 'Retrieve', the resource 'table of contents for a specific Hansard day', and format 'raw XML'. This differentiates it from sibling tools like hansard_get_table_of_contents_json (JSON) and hansard_get_fragment_xml (fragment, not TOC).

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?

The description implicitly suggests use for raw XML but provides no explicit guidance on when to choose this tool over alternatives like hansard_get_table_of_contents_json or hansard_get_fragment_xml. No exclusions or prerequisites are mentioned.

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

hansard_list_sitting_datesB

List all parliamentary sitting dates. Returns comprehensive list of when parliament has sat.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided; description does not disclose behavioral traits such as ordering, pagination, or data limitations. The phrase 'comprehensive list' is vague.

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?

Two sentences with no fluff. Front-loaded purpose. Extremely concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple list tool, but fails to describe return format or clarify relationship with sibling list tool. No output schema to compensate.

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?

Zero parameters, so schema coverage is 100%. Description adds minimal value but meets baseline for no-param tools.

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?

The description clearly states 'List all parliamentary sitting dates', which distinguishes it from search tools. However, it does not differentiate from the sibling 'hansard_list_sitting_date_types'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Lacks exclusions or context for choosing among siblings.

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

hansard_list_sitting_date_typesA

List all types of sitting dates (e.g., regular sitting, budget day, etc.).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It implies a safe read operation but does not explicitly state read-only, idempotent, or safety traits. The lack of behavioral details is acceptable for such a simple listing tool.

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?

Single sentence, no fluff. Every word contributes to clarifying the tool's output. Excellent conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description sufficiently explains the return value (list of types with examples). For a simple static list, this is adequate. Could mention if list is exhaustive or order, but not necessary.

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?

No parameters, and schema coverage is 100% (vacuously). Description adds value by providing examples of the output (types) which aids understanding beyond the empty schema.

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?

Description clearly states the tool lists all types of sitting dates, with concrete examples (regular sitting, budget day). This distinguishes it from sibling tools like hansard_list_sitting_dates which list actual dates.

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?

No explicit when-to-use or alternatives guidance. While the purpose is clear, the description does not differentiate from similar sibling tools or specify when to choose this over list_sitting_dates.

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

hansard_search_by_billA

Search Hansard records by bill name. Finds all mentions and debates related to a specific bill.

ParametersJSON Schema

Name	Required	Description	Default
`billName`	Yes	The name of the bill to search for (partial matching supported)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states it 'finds mentions and debates', omitting key traits like read-only nature, pagination, auth requirements, or behavior on no matches. This is insufficient for a search tool.

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?

Two short, front-loaded sentences with zero redundancy. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 1-parameter tool with no output schema, the description covers the core purpose but lacks details on return format, pagination, or edge cases. Minimal viable completeness given the simplicity.

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

Parameters3/5

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

Schema description coverage is 100% (parameter 'billName' documented with partial matching). The description adds no additional meaning beyond repeating 'by bill name', so baseline 3 is appropriate.

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 clearly states the verb ('Search'), resource ('Hansard records'), and scope ('by bill name', 'finds all mentions and debates'). It distinguishes effectively from sibling tools like hansard_search_by_year or hansard_search_by_speaker.

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?

The description implies use for bill-based search but provides no explicit guidance on when to use vs. alternatives, nor any exclusions or prerequisites. Sibling tool names hint at other search dimensions, but the description does not leverage that context.

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

hansard_search_by_dateA

Get detailed Hansard information for a specific date. Returns chamber information, document IDs, and whether transcripts are corrected.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	The date to search for in YYYY-MM-DD format (e.g., 2024-03-15)

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It mentions the tool returns data but does not clarify if it is read-only, whether it may have side effects, or any latency or rate limits. The description adds some context (returned fields) but lacks depth for a mutation-free tool.

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 concise (two sentences) and front-loaded with the primary action. No redundant information, and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a single parameter and no output schema, the description adequately explains what the tool does and what it returns. However, it could be improved by describing the format or structure of the returned data, but it is not insufficient.

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

Parameters3/5

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

Schema coverage is 100% and the parameter 'date' is described in the schema. The description does not add additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 clearly states the tool's function: 'Get detailed Hansard information for a specific date.' It also specifies what is returned (chamber information, document IDs, correction status). This distinguishes it from siblings like hansard_search_by_year or hansard_search_by_speaker, which have different scopes.

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?

The description implies when to use this tool (for a specific date) but does not explicitly mention when not to use it or suggest alternatives. However, the context from sibling tool names provides implicit guidance, and the description is clear enough for an agent to decide based on the need for date-specific data.

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

hansard_search_by_speakerA

Search Hansard records by speaker name. Supports wildcards (*) for partial matching. At least one of: parliamentSessionId, date range (startDate/endDate), or memberId must be provided.

ParametersJSON Schema

Name	Required	Description
`endDate`	No	End date for the search range in YYYY/MM/DD format (e.g., 2024/12/31)
`memberId`	No	The unique member ID to search for
`rowLimit`	No	Maximum number of results to return
`houseCode`	No	Filter by house: LH (Legislative Assembly/Lower House) or UH (Legislative Council/Upper House)
`startDate`	No	Start date for the search range in YYYY/MM/DD format (e.g., 2024/01/01)
`speakerName`	Yes	The name of the speaker to search for. Supports wildcards () for partial matching (e.g., 'Smith', 'Jones')
`parliamentSessionId`	No	The parliament session ID to limit the search to

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses wildcard support and required filters, but lacks details on pagination, error handling, or output format.

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 two sentences, no redundant information, and the key action is front-loaded. Every sentence is essential.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters and no output schema, the description covers the main purpose and constraints but does not explain the return value format or what to expect in the response, leaving some gaps for an agent.

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 description coverage is 100%, so baseline is 3. The description adds the constraint that at least one of the filtering parameters must be provided, which is not in the schema, adding value. Wildcard support is also mentioned, though schema already has that.

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 clearly states the verb 'Search' and resource 'Hansard records by speaker name', distinguishing it from sibling tools like hansard_search_by_year or hansard_search_by_date.

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?

The description provides explicit constraints: at least one of parliamentSessionId, date range, or memberId must be provided. It does not explicitly mention when not to use or list alternatives, but the context is clear.

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

hansard_search_by_yearA

Search all Hansard records for a specific year. Returns a list of sitting dates with links to Hansard documents. Coverage: September 1991 to present.

ParametersJSON Schema

Name	Required	Description	Default
`year`	Yes	The year to search for (e.g., 2024). Must be 1991 or later.

TDQS

A3.9/5.0

Behavior3/5

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

The description adds behavioral context: coverage from 'September 1991 to present.' However, with no annotations provided, it could further disclose any limitations, behavior on invalid years, or if it is a read-only operation. The coverage note is useful but incomplete without annotations.

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?

Two concise sentences front-loading the action and follow up with coverage context. Every sentence serves a purpose; no wasted 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 simple tool with one required parameter and no output schema, the description covers the action, return type (list of sitting dates with links), and temporal coverage. No additional context needed.

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

Parameters3/5

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

The single parameter 'year' is fully described in the schema (100% coverage). The description reinforces the year usage and coverage but adds little beyond the schema. For a single-parameter tool, this is adequate.

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 clearly states the action: 'Search all Hansard records for a specific year.' It specifies the resource and scope ('all Hansard records'), and distinguishes from sibling tools like hansard_search_by_date (by date range) and hansard_search_by_bill (by bill).

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?

The description implies use for searching a specific year but does not explicitly state when to use this tool versus alternatives like hansard_search_by_date or hansard_search_by_speaker. No exclusion criteria or context for when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

12 tool updatesv1.0.0Jul 28, 2026
- First observedhansard_get_fragment_html
- First observedhansard_get_fragment_xml
- First observedhansard_get_pdf_url
- First observedhansard_get_searchable_pdf_url
- First observedhansard_get_table_of_contents_json
- First observedhansard_get_table_of_contents_xml
- First observedhansard_list_sitting_date_types
- First observedhansard_list_sitting_dates
- First observedhansard_search_by_bill
- First observedhansard_search_by_date
- First observedhansard_search_by_speaker
- First observedhansard_search_by_year

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: search by year, date, bill, speaker; retrieve fragments in XML or HTML; get PDF URLs; table of contents in XML or JSON; list sitting dates and types. No overlapping functionality that would cause confusion.

Naming Consistency5/5

All tools follow a consistent 'hansard_verb_noun' pattern (e.g., hansard_search_by_year, hansard_get_fragment_xml). The naming is predictable and easy to understand.

Tool Count5/5

With 12 tools, the server is well-scoped for a Hansard document API. It covers search, retrieval in multiple formats (XML, HTML, PDF), table of contents, and date listings without being excessive.

Completeness4/5

The tool set covers core functionality: searching by year, date, bill, speaker; retrieving document fragments and PDFs; table of contents. Minor gap: no keyword search across all documents, but the existing search options handle common use cases.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

UK Parliament MCP Server from MCPBundles AOAuth
com.mcpbundles
Search MPs and Lords, fetch profiles, synopses, and Westminster constituencies
Government Data Search Open Data
2
UK Hansard MCP Server from MCPBundles AOAuth
com.mcpbundles
Search Parliamentary questions and motions from UK House of Commons
Government Data Search Open Data
2
GavelinOAuth
ai.gavelin
Search bills and speaker-attributed hearing transcripts across all 50 US state legislatures.
Government Data Search Open Data
21
SourceActs
com.sourceacts
Official EUR-Lex, UK, US, and gazette search, metadata fetch, and change-only watches.
Legal & Compliance Search
1

Related MCP Servers

Kokkai Minutes MCP Agent
Government Data Search Documentation Access
egegungordu
F
license
A
quality
D
maintenance
Provides a structured interface to the Japanese National Diet Library's parliamentary proceedings API, allowing AI models to search and retrieve Diet meeting records and speeches.
Updated a year ago (2025-06-04 06:34 UTC)
3
1
-
Taiwan Legislative Yuan MCP
Government Data Open Data Search
narumiruna
A
license
B
quality
A
maintenance
Provides comprehensive access to Taiwan's Legislative Yuan data including bills, committees, gazettes, meeting records, interpellations, laws, legislators, and IVOD recordings through the Legislative Yuan API v2.
Updated 7 days ago (2026-08-31 22:45 UTC)
42
6
MIT
LegCo Search MCP Server
Government Data Search Open Data
yellowcandle
F
license
Not graded
quality
C
maintenance
Provides comprehensive access to Hong Kong Legislative Council data including voting results, bills, parliamentary questions, and Hansard records. It supports real-time multi-word search capabilities and various transport protocols like SSE and WebSocket for easy integration.
Updated a year ago (2025-09-18 07:39 UTC)
2
-
openparliament-ca
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides access to Canadian parliamentary data including debates, bills, votes, politicians, and committees via the OpenParliament.ca civic-tech mirror.
Updated 12 days ago (2026-08-26 17:29 UTC)
10
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lawquarter/nsw-hansard-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

NSW Parliament Hansard MCP Server

Table of Contents

Features

Installation

Prerequisites

Install from npm

Install from Source

Configuration

Claude Desktop

Claude Code

Local Development

Available Tools

hansard_search_by_year

hansard_search_by_date

hansard_get_fragment_xml

hansard_get_fragment_html

hansard_get_pdf_url

hansard_get_searchable_pdf_url

hansard_get_table_of_contents_xml

hansard_get_table_of_contents_json

hansard_search_by_speaker

hansard_search_by_bill

hansard_list_sitting_dates

hansard_list_sitting_date_types

Available Resources

hansard://info

hansard://terms

Usage Examples

Searching for Recent Debates

Finding a Specific Day's Proceedings

Searching by Member

Tracking Legislation

API Reference

Endpoints Used

Data Coverage

Temporal Coverage

Content Types

Chambers

Terms of Use

NSW Parliament Copyright Notice

Permitted Use

Restrictions

Disclaimer

Full Terms

License

Contributing

Support

Acknowledgements

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API