Skip to main content
Glama
fasterinnerlooper

PlainGov-MCP

by fasterinnerlooper
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Retrieval-First MCP Server

Tagline: "Government information, retrieved and explained."

This MCP server provides government program information based solely on freshly retrieved documents from pre-approved sources. It operates on a strict retrieval-first principle, ensuring all responses are grounded in official sources without prior knowledge or assumptions.

Quick Start

npm install
npm run build
npm run inspector  # Test the server

See Deployment Guide for complete installation instructions.

Related MCP server: mcp-canada

What This MCP Does

  • Retrieves verbatim text from pre-approved government URLs

  • Provides retrieved text directly from official sources

  • Performs conservative eligibility assessments using rules engine

  • Includes source URLs and verification dates in all outputs

Strict compliance: No summaries, explanations, or answers without retrieval. Returns verbatim retrieved text only.

Scope (v1)

  • Country + Province: Canada + Alberta

  • Domains: Taxes & Benefits, Small Business Administration

  • Programs: GST Credit, Canada Child Benefit, Alberta Family Employment Tax Credit, GST Registration, Payroll Deductions

Tools Exposed

  1. explain_program(program_id) - Retrieved text from official source

  2. get_eligibility_criteria(program_id) - Retrieved text from official source

  3. eligibility_check(program_id, user_context) - Conservative eligibility assessment using rules engine

  4. generate_checklist(program_id) - Retrieved text from official source

  5. timeline(program_id) - Retrieved text from official source

  6. questions_for_professional(program_id) - Retrieved text from official source

Data Sources

  • Canada.ca

  • CRA official publications

  • Alberta.ca program pages

  • Public PDFs, bulletins, guides

No scraping forums. No third-party "tips".

Architecture

  • Retrieval-First Principle: All responses based on freshly retrieved documents from pre-approved URLs

  • Verbatim Storage: Retrieved text stored exactly as received

  • Retrieval Operation: Only verbatim text from pre-approved sources (no external data)

  • Rules Engine: Deterministic eligibility checks (no LLM involvement)

  • Error Handling: Retrieval failures return errors only, no fallbacks

  • Output Requirements: All responses include source URL and last_verified date

Design choice: Retrieval only. Fail loudly on constraint violations.

What We Explicitly DO NOT Build

❌ "How to minimise tax"
❌ "Best way to qualify"
❌ Edge-case exploitation
❌ Advice framed as instruction

We are a translator, not a strategist.

This keeps us out of trouble and attractive to institutions.

Pricing Strategy

  • Individual: $8–12/month CAD

  • Small business: $19–29/month

  • Professional / org: Seat-based or bulk licensing

Cheap insurance against mistakes.

Documentation

Getting Started

Technical Documentation

Support & Contributing

Installation

Quick Install

# 1. Install dependencies
npm install

# 2. Build the server
npm run build

# 3. Test with Inspector
npm run inspector

MCP Client Configuration

Add to your MCP client configuration (e.g., Claude Desktop):

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

{
  "mcpServers": {
    "plain-gov-mcp": {
      "command": "node",
      "args": [
        "/absolute/path/to/PlainGov-MCP/build/index.js"
      ]
    }
  }
}

Important: Use absolute paths and restart your MCP client after configuration.

See Deployment Guide for detailed instructions.

Usage

Available Tools

  1. explain_program - Get program information from official sources

  2. get_eligibility_criteria - Retrieve eligibility requirements

  3. eligibility_check - Check eligibility based on user context

  4. generate_checklist - Get application checklist

  5. timeline - Get key dates and deadlines

  6. questions_for_professional - Get questions to ask professionals

Example Usage

Check GST Credit eligibility:

User: "Am I eligible for GST Credit? Income: $45,000, live in Canada"

Server uses eligibility_check tool:
- Status: eligible
- Includes source URL and verification date
- Provides disclaimer

See Usage Examples for comprehensive scenarios.

Features

Retrieval-First Architecture

  • All responses based on freshly retrieved documents

  • No cached content or prior knowledge

  • Verbatim text from official sources

  • Source attribution in every response

Conservative Eligibility Assessment

  • Deterministic rules engine (no LLM)

  • Errs on side of caution

  • Clear status indicators (eligible/not_eligible/unclear)

  • Identifies missing information

Compliance & Trust

  • Strict adherence to retrieval-first constraints

  • Fail loudly on errors (no fallbacks)

  • Complete source traceability

  • Regular verification dates

See Architecture Documentation for technical details.

Compliance with Constraints

  • No summaries/explanations without retrieval: All content based on freshly retrieved documents

  • Retrieval restrictions: Only verbatim text from pre-approved sources, no prior knowledge

  • Retrieval failures: Return error objects only, no fallbacks

  • Output standards: Include source URL and last_verified date in all responses

  • Rules engine: Eligibility uses deterministic logic, no LLM

  • Fail loudly: System errors on any constraint violation

Ethical Guidelines

  • No advice or interpretation

  • Conservative eligibility assessments

  • Direct to official sources only

  • Clear disclaimers: "This is not advice"

  • No optimization or loophole suggestions

Testing

Manual Testing with Inspector

npm run inspector

Open the provided URL in your browser to test tools interactively.

Automated Testing

See Testing Guide for comprehensive testing procedures.

Troubleshooting

Common issues and solutions are documented in the Troubleshooting Guide.

Quick fixes:

  • Server not appearing? Check configuration file syntax and restart client

  • Retrieval failures? Verify internet connection

  • Tools not working? Test with MCP Inspector

Contributing

We welcome contributions that align with the retrieval-first principles and core mission.

Before contributing:

  1. Read Contributing Guidelines

  2. Review Architecture Documentation

  3. Understand constraint compliance requirements

Ways to contribute:

  • Add new government programs

  • Improve documentation

  • Report bugs

  • Suggest enhancements

See CONTRIBUTING.md for detailed guidelines.

Project Status

Current Version: 0.1.0 Status: Production-ready with comprehensive documentation

Completed:

  • ✅ Core retrieval-first implementation

  • ✅ 5 government programs (Canada & Alberta)

  • ✅ 6 tools for program information

  • ✅ Deterministic eligibility rules engine

  • ✅ Comprehensive documentation suite

  • ✅ MCP Inspector integration

  • ✅ Error handling and compliance mechanisms

Roadmap:

  • LLM integration for formatting (with strict constraints)

  • Additional provinces and programs

  • Caching layer with time-based invalidation

  • Enhanced rules engine

  • Automated testing suite

Support

Documentation: Start with Deployment Guide Issues: Check Troubleshooting Guide Questions: Review Usage Examples Technical: See Architecture Documentation

License

This project is licensed under the MIT License - see the LICENSE file for details.

Acknowledgments

Built with:

Last Updated: 2026-01-10

Available Tools

6 tools
eligibility_checkC

Check eligibility for a program based on user context

ParametersJSON Schema
NameRequiredDescriptionDefault
program_idYesID of the program to check
user_contextYes

TDQS

C2.8/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 disclose behavioral traits. It only says 'Check eligibility', implying a read operation but with no details on side effects, permissions, error conditions, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but too brief to be informative. It does not front-load important details; it merely restates the tool's name.

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

Completeness1/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 behavioral transparency, the description fails to explain return values, error handling, or how to properly structure the 'user_context' parameter. This is severely incomplete for an AI agent.

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

Parameters2/5

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

The schema covers only 50% of parameters descriptively: 'program_id' has an enum and description, but 'user_context' lacks any documentation in the schema or description. The tool description adds no meaning beyond the enum for program_id.

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 'Check' and the resource 'eligibility for a program', and it distinguishes from siblings like 'explain_program' and 'get_eligibility_criteria' by focusing on the actual eligibility check rather than explanation or criteria listing.

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 alternatives like 'get_eligibility_criteria' or 'explain_program'. There is no mention of prerequisites, context, or exclusions.

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

explain_programA

Get plain-language explanation of a government program

ParametersJSON Schema
NameRequiredDescriptionDefault
program_idYesID of the program to explain

TDQS

A3.5/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 states the tool returns a 'plain-language explanation' but does not describe the output format, content scope, or any behavioral traits like read-only nature. This is minimal disclosure.

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 sentence, front-loaded with the action and resource. No unnecessary words.

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 simple input (single enum parameter) and no output schema, the description is adequate but lacks details on what the explanation covers (e.g., eligibility, benefits, steps). Could provide more context for an agent.

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 program_id enumerated. The description adds no additional meaning beyond the schema. Baseline of 3 is appropriate since the schema sufficiently describes the parameter.

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 returns a plain-language explanation of a government program. It distinguishes from sibling tools like eligibility_check and generate_checklist by focusing on explanation rather than eligibility or actions.

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 that the tool is used when a user wants an explanation, but it does not explicitly state when to use this tool over siblings or provide exclusion criteria. No guidance on alternatives is given.

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

generate_checklistC

Generate a step-by-step checklist for applying to a program

ParametersJSON Schema
NameRequiredDescriptionDefault
program_idYesID of the program

TDQS

C2.9/5.0
Behavior2/5

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

The description does not disclose any behavioral traits, such as what the checklist contains, whether it is tailored to the user, or potential errors. With no annotations, the description should provide more 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?

The description is a single sentence, concise and front-loaded. It could be slightly expanded to include usage context, but it is not overly long.

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

Completeness2/5

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

For a tool with one enum parameter and no output schema, the description is minimal. It lacks details about the checklist format, prerequisites, or behavior, especially given sibling tools that might have overlapping purposes.

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 input schema already covers both the parameter name and its enum values with a description. The description adds no additional meaning beyond the schema, so it meets the baseline for 100% coverage.

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 'Generate a step-by-step checklist for applying to a program', specifying a verb and resource. However, it does not distinguish from sibling tools like 'explain_program' or 'eligibility_check', which also relate to programs.

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 provided on when to use this tool versus alternatives such as 'eligibility_check' or 'explain_program'. The description lacks context for appropriate usage.

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

get_eligibility_criteriaB

Get eligibility criteria for a program

ParametersJSON Schema
NameRequiredDescriptionDefault
program_idYesID of the program

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral traits. It only states 'get eligibility criteria' but does not disclose whether the operation is read-only, requires authentication, has rate limits, or any side effects. This lack of transparency is a significant gap.

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 a single sentence, front-loaded and efficient. It conveys the core purpose without extraneous words. However, it could be slightly more structured by mentioning the parameter explicitly, but overall it is concise.

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

Completeness2/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 should explain the return format or behavior, but it does not. It also lacks information about what constitutes 'eligibility criteria' and error handling. For a simple tool, this is 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% with the program_id parameter fully described (enum values, type). The description adds no additional meaning beyond the schema. 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 'Get eligibility criteria for a program' clearly states the verb (get) and resource (eligibility criteria for a program). It effectively distinguishes from sibling tools like eligibility_check and explain_program, which serve different purposes.

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 is provided on when to use this tool versus siblings, such as when to choose get_eligibility_criteria over eligibility_check or questions_for_professional. There are no contextual or exclusionary statements.

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

questions_for_professionalB

Get questions to ask a professional about a program

ParametersJSON Schema
NameRequiredDescriptionDefault
program_idYesID of the program

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, and the description does not elaborate on behavioral aspects. It does not state whether the tool is read-only, if it requires authentication, or what the output entails. The description is minimal.

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 a single, concise sentence that directly communicates the tool's purpose. No extraneous text. However, it could be slightly expanded to include context without losing conciseness.

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 tool with one parameter and no output schema, the description provides minimal context. It lacks details about the return format (e.g., list of questions, structure) or typical use cases. While functional, it is on the verge of being under-specified.

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 input schema has 100% coverage for the single parameter 'program_id', with a description and enum values. The tool description does not add any additional semantic information beyond what the schema provides. 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 'Get questions to ask a professional about a program' clearly states the tool's function: it retrieves a set of questions. The tool name reinforces this purpose. It is distinct from sibling tools like eligibility_check or explain_program, which serve different purposes.

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 usage guidance is provided. The description does not specify when to use this tool versus alternatives such as get_eligibility_criteria or timeline. There is no mention of prerequisites or context.

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

timelineA

Get key dates and deadlines for a program

ParametersJSON Schema
NameRequiredDescriptionDefault
program_idYesID of the program

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, and the description only states the purpose without revealing behavioral traits such as read-only nature, return format, or any limitations. The tool is simple but could benefit from clarifying that it returns a list of dates/deadlines.

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?

Description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's 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?

Given the tool's simplicity (single enum parameter, no output schema), the description is minimally adequate but lacks details on return value or scope (e.g., 'Returns a list of key dates with descriptions'). This gap reduces 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 100%, and the description does not add extra meaning to the program_id parameter beyond what the enum and schema description already provide. The description does not explain how the parameter affects the output.

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 specifies the action (Get) and the resource (key dates and deadlines for a program). It effectively distinguishes from sibling tools like eligibility_check, explain_program, etc., which focus on other aspects.

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 usage when timeline information is needed, but lacks explicit guidance on when not to use this tool or alternatives. No exclusions or context provided beyond the basic purpose.

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.

  1. 6 tool updatesv0.1.0
    • First observedeligibility_check
    • First observedexplain_program
    • First observedgenerate_checklist
    • First observedget_eligibility_criteria
    • First observedquestions_for_professional
    • First observedtimeline
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a distinct purpose: eligibility check, program explanation, checklist generation, criteria retrieval, professional questions, and timeline. No overlap or ambiguity.

Naming Consistency4/5

Most tool names follow a verb_noun or noun_phrase pattern with underscores. 'timeline' uses a bare noun instead of verb_noun, but the rest are consistent.

Tool Count5/5

Six tools is an appropriate count for a focused government program assistant, covering key user needs without being overwhelming or too sparse.

Completeness4/5

The tool set covers eligibility, explanation, checklist, criteria, professional questions, and deadlines. A minor gap could be a search/discovery tool for programs, but the set is largely complete for its intended use.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • mcp-canada

    ReyemTech
    A
    license
    A
    quality
    B
    maintenance
    MCP server giving AI agents structured access to Canadian federal, provincial, and municipal government data.
    5
    59
    MIT

  • 사장님 머니핏 (MoneyFit)

    wjd0ha
    F
    license
    Not graded
    quality
    B
    maintenance
    Analyzes government support program announcements and business profiles to determine eligibility, identify missing information, detect risks, and generate application plans for small business owners.
    -

  • mcp-statscan

    pipeworx-io
    A
    license
    Not graded
    quality
    F
    maintenance
    Provides access to Statistics Canada official statistics without authentication, enabling AI agents to query Canadian economic and demographic data.
    4
    MIT

Latest Blog Posts

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/fasterinnerlooper/PlainGov-MCP'

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