kra-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.3
Disambiguation5/5
Each tool targets a distinct tax concept: PAYE calculation, PIN registration, VAT, filing calendar, withholding rates, and tax incentives. There is no overlap in purpose, making selection unambiguous.
Naming Consistency5/5
All names use lowercase snake_case and follow a descriptive noun-based pattern (e.g., paye_calculator, vat_guide). The style is consistent throughout, with no mixing of conventions or ambiguous verbs.
Tool Count5/5
With 6 tools, the server is well-scoped for a Kenya tax information and calculator demo. Each tool covers a core tax area without unnecessary bloat.
Completeness3/5
The set covers common tax topics like PAYE, VAT, and withholding, but notably lacks tools for corporate income tax, capital gains, or excise duty. As a demo, it is acceptable, but for a comprehensive tax server there are clear gaps.
Average 2.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 32 commits in the last 12 weeks
- Last stable release on July 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It only states a topic ('Kenya investment tax incentives and reliefs') and 'DEMO', but doesn't disclose whether the tool returns static information, requires parameters, or what the output structure is. The word 'DEMO' hints at limited functionality but is left undefined, leaving the agent uncertain about side effects or data freshness.
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 only two sentences and gets straight to the topic, but 'DEMO' is a filler word that doesn't earn its place. It's concise but under-specified; the brevity is not a substitute for missing semantic content. A score of 3 reflects acceptable minimalism with room for improvement.
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?
Even though an output schema exists and there is only one optional parameter, the description leaves out core meaning: it doesn't explain what the tool actually does, what kind of information it returns, or how the sector parameter influences the output. Given that siblings like 'vat_guide' and 'pin_registration_guide' exist, this description is too thin to support reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one optional 'sector' parameter, but the description never mentions it. With schema description coverage at 0%, the description fails to compensate by explaining valid values, default behavior, or how sector affects the results. The agent is left to guess whether the parameter filters incentives by industry or has other semantics.
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 states the tool's subject as 'Kenya investment tax incentives and reliefs', which clearly distinguishes it from sibling tools like paye_calculator or vat_guide. However, it lacks an explicit verb, so it doesn't say whether the tool lists, explains, or calculates these incentives. The 'DEMO' suffix adds noise but does not obscure the topic.
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 compared to siblings. It doesn't mention prerequisites, alternative tools, or scenarios where this guide would be appropriate. The presence of sibling tools like withholding_tax_rates or tax_filing_calendar emphasizes the need for differentiation, but none is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It only says 'guidance' and 'DEMO', neither of which clarifies what the tool actually does, how it responds, or what limitations exist. The 'DEMO' label hints at incompleteness but is not elaborated.
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 very short and front-loaded with the topic, which is positive. However, it is under-specified and includes the ambiguous 'DEMO' tag. It is concise but at the expense of essential operational detail.
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?
Despite having only one parameter and an output schema, the description provides minimal operational context. An agent cannot infer how to formulate a query or what response to expect. The 'DEMO' label creates additional uncertainty, and no details about the output schema are given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'query' with no description, and the tool description does not mention it at all. With 0% schema description coverage, the agent has no clue what to put in the query, how to format it, or what kinds of questions are valid.
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 the tool provides guidance on Kenya VAT registration, rates, and filing. While it lacks a strong verb, the noun 'guidance' makes the purpose clear. It is also distinguishable from sibling tools that cover PAYE, PIN, tax calendar, withholding, and incentives.
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 gives no advice on when to use this tool versus alternatives. It does not mention that it is for VAT-specific queries or exclude other tax topics. No explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'Compute Kenya PAYE income tax' and adds 'DEMO,' but does not explain key behaviors such as how NHIF/NSSF options affect the calculation, what tax rates/reliefs are applied, or whether results are approximate. This is essentially no disclosure.
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 extremely concise—a single sentence followed by 'DEMO.' It is front-loaded with the core purpose and contains no fluff. However, the 'DEMO' tag is cryptic and could be considered unnecessary, though it does not harm the structure.
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?
Given the tool's complexity (PAYE calculation with optional NHIF/NSSF) and the absence of annotations or parameter descriptions, the description is woefully incomplete. It does not mention what the output looks like (despite an output schema existing), any prerequisites, or tax year specifics beyond '2025.' A calculator tool needs much more context to be used safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to parameters. It does not mention 'annual_gross_income_kes', 'include_nhif', or 'include_nssf' at all. The booleans' semantics are completely unexplained, leaving the agent without clues about how these inputs influence the calculation beyond their names.
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 purpose: 'Compute Kenya PAYE income tax for 2025 tax year.' It uses a specific verb ('Compute'), identifies the resource ('Kenya PAYE income tax'), and specifies the tax year, which fully distinguishes it from the sibling guide tools. Even though 'DEMO' is added, it does not obscure the primary function.
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 tool's use is implied by its name and description as a calculator for 2025 Kenyan PAYE, but there is no explicit guidance on when to use it versus alternatives. Sibling tools are guides, so the calculation context is inferred, but no alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, placing full burden on the description. The description only says 'DEMO,' which is ambiguous and does not disclose behavior such as whether data is real, what the response structure is, or any limitations. No read-only or safety information is provided.
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 very concise and front-loaded with the tool's purpose. However, the 'DEMO' sentence is cryptic and adds little actionable value, so it is not perfectly efficient.
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?
The tool is simple with one optional parameter and an output schema, so the description is nearly adequate. However, it lacks usage context, possible payment_type values, and an explanation of the 'DEMO' caveat, leaving gaps for an agent to resolve.
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?
Schema description coverage is 0%, so the description must compensate. It mentions 'by payment type,' which clarifies that payment_type is a filter, but it does not provide allowed values, formats, examples, or distinction between null and unspecified values. This is minimally helpful but insufficient for confident invocation.
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 identifies the tool's topic ('Kenya withholding tax rates') and the dimension by which rates are organized ('by payment type'). It is distinct from the sibling tools like paye_calculator or vat_guide by tax type, though it does not explicitly name alternatives.
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 the sibling tools such as paye_calculator or vat_guide. The usage context is merely implied by the title and description, with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only states the topic and 'DEMO' without explaining what that implies (e.g., demo data, read-only nature, return format, or limitations).
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 concise and front-loaded with the topic. However, the 'DEMO' tag is cryptic and adds little value, making the sentence only minimally informative despite its brevity.
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 has no parameters and an output schema exists, the description's brevity is somewhat acceptable. However, the 'DEMO' flag raises questions about data validity and usage that are not addressed, leaving the tool incomplete in context.
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?
The schema has zero parameters, so the baseline of 4 applies. There is no need for parameter descriptions, and the description does not need to compensate for any missing parameter information.
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 the tool provides Kenya tax filing deadlines and calendar, which distinguishes it from sibling tools like paye_calculator and vat_guide. Although it lacks a verb, the noun phrase is specific about the resource and its scope.
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 given on when to use this tool versus alternatives. The 'DEMO' suffix hints at a demonstration purpose but is not explained, leaving the intended use case ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 says 'DEMO', hinting at limited functionality, but does not disclose whether the tool is read-only, what it returns, or any side effects. This lack of detail leaves the agent guessing about the tool's behavior.
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 very short and front-loaded, with each sentence (purpose and demo flag) contributing value. It is concise, though perhaps an example of under-specification rather than tight writing.
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 the tool has an output schema and one parameter, the description is incomplete. It does not explain how applicant_type influences the guide, what the output format or content is, or provide any disclaimers beyond 'DEMO'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, applicant_type, with 0% description coverage. The description does not mention it at all, adding no meaning beyond the bare name and default. The agent cannot infer valid values or how it affects the guide.
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 it is a guide for registering for a KRA PIN, using a specific verb and resource. It is distinct from sibling tools like paye_calculator and vat_guide, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is clear: it is for PIN registration guidance. However, it does not explicitly mention when to use this over sibling guides like vat_guide or tax_incentives_guide, so there are no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kra-mcp MCP server](https://glama.ai/mcp/servers/gabrielmahia/kra-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gabrielmahia/kra-mcp)

Score Badge

Copy to your README.md:

[![kra-mcp MCP server](https://glama.ai/mcp/servers/gabrielmahia/kra-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gabrielmahia/kra-mcp)

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/gabrielmahia/kra-mcp'

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