klaxon

by ali-cabukel

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but create_issue, create_github_issue, and simulate_upstream_ingest could be confused without careful reading. Descriptions clarify the differences, so ambiguity is limited.
Naming Consistency4/5
Most names follow a verb_noun pattern (search_issues, get_issue, create_issue), but issue_stats breaks the pattern by using a noun phrase instead of get_issue_stats. Otherwise naming is consistent and predictable.
Tool Count5/5
Ten tools cover the core incident issue workflow without redundancy, staying within a reasonable and focused scope.
Completeness4/5
The toolset covers create, read, search, update, status changes, comments, and simulated integrations. It lacks an explicit delete/archive operation, but that may be intentionally excluded from the domain.
Average 3.1/5 across 10 of 10 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description of side effects, permissions, idempotency, or return behavior, the description fails to disclose what happens when the tool is invoked. This is especially problematic for a write operation like adding a comment.
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 and contains no unnecessary words. It is a single clear sentence. However, its brevity comes at the cost of omitting essential details, so it is not maximally effective despite being succinct.
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?
The description lacks any context about the 'issue' entity, the expected input format, the result of the operation, or any related constraints. It provides insufficient information for an agent to use the tool correctly in a real workflow.
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 does not include descriptions for any parameters (public_id, body, author), and the tool description also does not explain what each parameter means or how they should be used. The agent receives no semantic information beyond the bare parameter names.
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 action (add) and the object (a comment to an issue), which distinguishes it from siblings like create_issue or update_issue. However, it does not elaborate on the nature of the issue or any additional context, so it is not maximally explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 the sibling tools, nor does it mention any prerequisites, constraints, or typical scenarios. It is a bare statement with no usage context.
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?
Annotations are absent, so the description must carry the full behavioral burden. It only repeats the verb 'update' from the tool name and gives no information about partial-update semantics, null-field behavior, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than effectively concise. Given eight parameters and no additional context, the single sentence does not provide enough substance to be considered well-structured.
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 eight parameters, no annotations, no usage guidance, and 0% schema coverage, this description is far from complete for reliable tool invocation. The output schema reduces the need to document return values, but the missing parameter semantics and behavioral context remain critical gaps.
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%, and the description mentions no parameters at all. Fields such as features_json, labels, assignee, reporter, and severity are left entirely to schema titles, providing no practical guidance for constructing a correct update.
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 action (update) and the target (an existing issue), and 'fields' suggests it is the general update tool rather than update_issue_status. It does not enumerate which fields or explicitly contrast with siblings, so it is clear but not fully differentiated.
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 create_issue, update_issue_status, get_issue, or search_issues. An agent would have to infer usage from the tool name and schema, which is insufficient routing guidance.
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 behavioral disclosure. It says 'simulate' but does not clarify whether a real issue record is created, whether side effects occur (e.g., via create_github_issue parameter), or whether the operation is reversible. This leaves critical behavior ambiguous for a simulation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is underspecified for a tool with six parameters. It lacks structure or any breakdown of inputs, outputs, or side effects. It is more under-specified than concise, earning a low score.
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?
The tool has six parameters, one required, and an output schema, yet the description provides no context about expected inputs, return values, or behavioral nuances. It does not explain what the simulated issue represents, how to interpret the output, or when this tool is appropriate. The description is grossly incomplete for the tool's complexity.
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%, and the description mentions none of the six parameters (kind, title, severity, description, features_json, create_github_issue). The description provides no semantic meaning beyond the raw schema, failing to compensate for the lack of schema descriptions.
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 a specific action ('simulate an upstream system creating an issue') and includes 'source=upstream', which distinguishes it from generic issue creation tools. However, it does not explicitly name sibling tools or contrast with create_issue, so it is clear but not fully differentiated.
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?
There is no guidance on when to use this tool versus alternatives like create_issue or simulate_github_issue. It does not mention any prerequisites, exclusions, or conditions that would prompt an agent to select this tool. The context is implied but not stated.
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 present, and the description only states the basic mutation without noting side effects, permissions, or reversibility. The agent lacks information about what happens when a comment is added or whether status changes are restricted.
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 concise sentence with no unnecessary words or redundant information. It is efficient and directly conveys the core functionality.
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?
With no annotations, no output schema details, and minimal parameter guidance, the description lacks essential context such as valid status values, comment behavior, or expected return. The agent is left with too many unknowns to invoke this reliably.
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 covers 0% of parameter descriptions, and the description does not elaborate on any of the four parameters. Terms like public_id, status, and actor are unexplained, leaving the agent to guess their meaning or allowed values.
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 action (change status) and the optional comment. It distinguishes from sibling tools like create_issue and add_comment, though it overlaps with update_issue without explicit differentiation.
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 the related update_issue or add_comment tools. The description does not mention conditions or alternatives, leaving the agent to infer usage context.
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?
The verb 'list' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention any permissions, limitations, or potential impacts. There are no annotations to clarify behavior, so this remains ambiguous.
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 concise and front-loaded with the primary action and object. It does not waste words, though it could benefit from slightly more detail. The structure is clear and easy to parse.
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 description covers the core action and filter, but lacks details about the output structure, pagination behavior, or any nuances like sorting or default ordering. Without these, an agent might not fully understand what to expect when calling this tool.
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 provides only titles for the parameters (Limit, Public Id) with no descriptions. The description text adds that public_id is for filtering by issue, but does not clarify its format, purpose, or how limit affects results. Overall, parameter coverage is low.
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 'List' and the resource 'simulated side effects', and it specifies an optional filter by issue public_id. This distinguishes it from sibling tools like search_issues or get_issue, which have 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?
The description gives minimal guidance on when to use this tool, only mentioning the optional filter. It does not explain when to prefer this over alternatives like search_issues or get_issue, nor does it provide any usage context or examples.
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 provided, so the description is the only source of behavioral information. While 'Create' implies a write action, the description does not disclose any side effects, permissions required, potential errors, or what happens upon success (e.g., whether it returns the created issue). This leaves the tool's behavioral impact largely opaque, earning a low score.
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 extremely concise, consisting of two sentences with no redundant words. It packs essential parameter formatting rules into a compact format, making it easy to parse and remember. There is no fluff or unnecessary elaboration, which is ideal for a tool description.
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 description gives the core purpose and a few parameter format hints, but it lacks context about the expected output (despite having an output schema), possible error conditions, or how this tool fits into the broader workflow alongside siblings like update_issue_status and add_comment. It does not clarify the difference between this and create_github_issue. This leaves gaps that an agent would need to infer, making the description moderately complete.
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 provides zero description coverage for the 10 parameters, so the description is the only source of meaning. It clarifies only two parameters (labels and features_json), while the remaining eight (kind, title, source, status, assignee, reporter, severity, description) have no semantic explanation. This is insufficient for an agent to confidently populate many fields, hence a low score.
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 ('Create') and the object ('a new incident issue'), which precisely conveys the tool's primary function. It also distinguishes itself from sibling tools like search_issues, get_issue, and update_issue by focusing on creation, and the mention of 'incident' helps differentiate it from create_github_issue.
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 provides some usage guidance by specifying that labels must be comma-separated and features_json must be a JSON object, which helps format those parameters correctly. However, it does not explicitly state when to use this tool versus alternatives like create_github_issue, nor does it mention any prerequisites or typical use cases. The guidance is partially present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The term 'Search' suggests a read-only operation, and no destructive behavior is indicated. However, without annotations or additional detail, the agent is not told whether results are ordered, paginated, filtered by default, or limited in any other way.
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, direct sentence with no redundant content. It front-loads the action and resource, then lists the search dimensions clearly.
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 five parameters and no parameter descriptions or annotations, the one-sentence description leaves significant gaps. It does not explain possible field values, output shape, default behavior, or common usage context beyond the bare search action.
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 provides no descriptions or enums for any of the five optional parameters. The description names kind, status, and severity as filters, but does not explain accepted formats, how 'query' maps to text search, or how 'limit' behaves. The agent must guess at parameter semantics.
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', the resource 'incident issues', and the main criteria: text, kind, status, or severity. It is specific enough to distinguish this tool from siblings like get_issue, issue_stats, and create_issue.
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 identifies the general purpose and searchable fields, but it does not explicitly state when to prefer search_issues over get_issue or issue_stats, nor does it mention narrowing criteria or edge cases. Some inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It indicates a read-only aggregation operation through 'Aggregate counts' but does not explicitly state that issues are not modified, nor does it disclose any limits, pagination, or error behavior. The ISO-8601 note for timestamps is useful but pertains to parameters, not 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?
The description is two sentences with zero filler. The core purpose is front-loaded, and the timestamp format detail is added only as needed. It is appropriately sized for a simple aggregation 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 the tool's simplicity, an output schema, and all-optional parameters, the description covers the essential context: what it aggregates, by which dimensions, and the timestamp format. Minor gaps like inclusivity of since/until are not critical for a counts tool, and the output schema handles return structure.
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 0%, so the description must compensate. It explains that since/until are ISO-8601 timestamps and implies group_by accepts status, kind, severity, or source. However, it does not explicitly link these values to the group_by parameter or list all possible values, leaving some ambiguity for an agent.
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 uses a specific verb ('Aggregate') and resource ('issue counts') and lists grouping dimensions (status, kind, severity, or source). This clearly differentiates it from sibling tools like search_issues (which likely returns lists) and get_issue (single issue). However, it does not explicitly name an alternative or state what it is not, so it is not a 5.
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 for count-based aggregation rather than listing, but it does not explicitly say when to use this tool versus search_issues or get_issue. There is no mention of exclusions or prerequisites, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must disclose behavior. It states that the action is 'logged as a side effect only', which transparently conveys that no actual GitHub issue will be created. This is sufficient transparency, though it does not elaborate on what logging entails.
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, focused sentence that conveys the tool's core purpose and side-effect behavior. It does not waste words and is easy to parse.
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?
While the tool is distinguishable from create_issue via the word 'Simulate', the description lacks essential context about parameter meanings and the relationship to the incident workflow. It also does not clarify when simulation is preferred over real creation, beyond the implicit side-effect distinction.
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 provides only parameter names and types, with no descriptions. The tool description does not explain what public_id, title, or body represent, nor how they are used in the simulation. This leaves the agent guessing about required and optional fields, especially public_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 that this tool simulates opening a GitHub issue for an incident, distinguishing it from real creation. The verb 'Simulate' and phrase 'logged as a side effect only' make the purpose unambiguous, especially alongside the sibling create_issue tool.
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 it: whenever a simulated issue-opening is needed for an incident and no real side effects are desired. It does not explicitly state 'use this instead of create_issue when testing', but the word 'Simulate' and the side-effect note provide clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden. The verb 'Get' clearly indicates a read-only operation with no side effects. However, it does not explicitly state that it is non-destructive or what happens if the issue is not found, which would be more transparent.
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, clear sentence with no unnecessary words. It is well-structured and directly conveys the purpose and the parameter. The example is concise and helpful without adding bulk.
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 read operation, the description is adequately complete. The output schema is separate, so return values are not required in the description. It could mention error handling or explicit output shape, but the core functionality is well covered. Given the tool's simplicity, it is sufficiently complete.
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 input schema provides no description for the 'public_id' parameter, but the tool description compensates by explaining it is the issue identifier and giving an example format (e.g. INC-0001). This is sufficient for a single, self-explanatory parameter, though a schema-level description would be ideal.
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 full details for an issue by public_id'. It specifies the resource (issue), the exact identifier needed (public_id), and even provides a format example (e.g. INC-0001). This is specific and distinguishes it from sibling tools like search_issues or issue_stats.
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 when to use it (when you have a public_id and need full details), but it does not explicitly mention alternatives or conditions for using other tools. For example, it does not say to use search_issues when the ID is unknown. Some guidance on sibling tools would improve clarity.
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

klaxon MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![klaxon MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/ali-cabukel/klaxon/badges/card.svg)](https://glama.ai/mcp/servers/ali-cabukel/klaxon)

Score Badge

Copy to your README.md:

[![klaxon MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/ali-cabukel/klaxon/badges/score.svg)](https://glama.ai/mcp/servers/ali-cabukel/klaxon)

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/ali-cabukel/klaxon'

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