ircv3-mcp

Server Quality Checklist

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

Latest release: v0.1.8
Disambiguation5/5
Each tool targets a distinct concern: connection state, history, live events, messaging, typing, reactions, redaction, channel management, read markers, and raw protocol access. Even the two sending tools (irc_send_message and irc_send_with_typing) are clearly separated by the typing-indicator behavior, and the descriptions explicitly disambiguate irc_read_history from irc_recent_events.
Naming Consistency4/5
All tool names share the irc_ prefix and use snake_case. Most follow a verb_noun pattern (irc_list_networks, irc_send_message, irc_mark_read), but a few are exceptions (irc_status, irc_whois, irc_recent_events). These are minor and do not confuse the overall pattern.
Tool Count4/5
17 tools is slightly above the ideal 3-15 range, but each covers a meaningful part of IRC communication (connection, history, live events, sending, typing, channels, raw). The count is justified by the breadth of the IRCv3 feature set and does not feel bloated.
Completeness4/5
The toolset covers core IRC workflows: joining/parting, sending messages, typing indicators, reactions, redaction, history, live events, member lists, whois, and read markers. Minor gaps exist (e.g., no explicit topic/mode/nick change tools), but the raw send tool covers edge cases, so the surface is fairly complete for an IRC client.
Average 3.8/5 across 15 of 17 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on June 20, 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?
The annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds no additional behavioral context beyond the literal 'look up information.' It does not mention what data is returned, whether authentication is needed, or any rate-limiting/availability caveats. The description is consistent with annotations but contributes nothing beyond them.
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, front-loaded sentence with no filler or redundant phrasing. It is concise, though extremely terse—it could afford a bit more detail without losing efficiency.
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 only 2 parameters, one required, and an output schema present, the description is minimally adequate for basic invocation. However, it does not explain the optional account parameter, note any usage caveats, or reference sibling tools. The agent is left with insufficient context to handle edge cases or choose between similar lookup tools.
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 clarify parameters. It only implicitly defines 'nick' by saying 'about a nick,' but the optional 'account' parameter is completely unexplained. This is a significant gap, especially for a WHOIS tool where 'account' could refer to a separate account-based lookup.
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 'Look up information about a nick on IRC' uses a specific verb+resource pattern, clearly identifying the tool as a read-only query for nick information. This distinguishes it from sibling tools like send_message, join, or part, which perform actions rather than lookups.
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 about when to use this tool versus alternatives such as irc_list_members or irc_recent_events. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name and description alone.
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?
Annotations already declare readOnlyHint and openWorldHint, so the read-only nature is covered. The description adds context that msgid values are available for reply/react/redact, but does not disclose pagination behavior, authentication, or other operational details. This adds some value but not extensive context.
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 concise, front-loaded sentences with no fluff. The first sentence states the primary purpose; the second adds actionable guidance about msgid usage. It is appropriately sized for the tool.
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?
The tool has moderate complexity with 6 parameters, including mode and msgid for pagination, but the description fails to explain how these parameters interact. It relies on the output schema and annotations, yet leaves out crucial operational context like how to fetch messages around a specific msgid or what format options exist. The description is incomplete for a tool of this complexity.
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 only clarifies that 'target' is a channel or DM and hints that 'msgid' is used from results, but it does not explain modes (before/after/around), limit, format, or account. This leaves most parameters semantically underdefined.
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 it fetches recent messages from a channel or DM, with a specific verb and resource. While it doesn't explicitly differentiate from sibling tools like irc_recent_events or irc_list_conversations, the title 'Read IRC message history' and the action of fetching messages make the purpose clear.
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 sentence 'Use msgid values from results for reply/react/redact' implies the tool should be used to obtain message IDs for subsequent actions, but no explicit when-to-use or alternatives are provided. This is implied usage rather than clear guidance.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is understood. The description adds the 'had activity' filter, which is useful, but it does not disclose default time windows, result ordering, pagination, or how 'active' is determined. Some behavioral context is added beyond 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?
The description is a single sentence that is concise and front-loaded with the essential action and scope. Every word contributes meaning, and there is no fluff or redundancy.
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 an output schema, the tool requires more context for proper use. The three optional parameters are entirely unexplained, and there is no guidance on how the time window works or what limits apply. This makes the description inadequate for an agent to correctly invoke the tool in varied situations.
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% for three parameters (hours, limit, account), and the description provides no explanation of these parameters. The agent cannot infer units (hours), meaning of limit, or account scoping from either the description or schema, which is a critical gap.
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 a specific verb ('List') and resource ('channels and DMs') with a clear scope ('had activity in the given time window'). This clearly distinguishes it from sibling tools like irc_list_networks (networks) or irc_read_history (message content).
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 the tool is for finding active conversations within a time window, but it does not explicitly state when to use this tool versus alternatives (e.g., irc_read_history for individual messages) nor any exclusions or prerequisites. Context is present but no guidance is given.
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?
Annotations already indicate this is a non-read-only, non-destructive action. The description does not contradict this, but it also adds no extra behavioral context (e.g., side effects, permissions, or error conditions). It is consistent but not enlightening beyond the 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?
The entire description is a single sentence, front-loaded with the action and resource. It is extremely concise and contains no filler 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 simplicity of the tool and the presence of an output schema, the description is minimally adequate. However, the unexplained 'account' parameter and lack of any usage context mean it is not fully complete for an agent to confidently use all options.
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?
With 0% schema description coverage, the description must explain parameters. It clarifies that 'key' is a password, but the 'account' parameter is completely undocumented. This leaves a meaningful gap in understanding how to invoke the tool correctly.
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 ('Join a channel') with the specific resource (IRC channel) and adds the optional key/password detail. This unambiguously distinguishes it from siblings like irc_part (leave) and messaging tools.
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 alternatives. There is no mention of prerequisites, such as being connected to a network, or when to use irc_part or other related tools. The description only explains the action itself.
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 readOnlyHint annotation already signals a safe read operation, and the description adds the 'mode prefixes' detail. However, no additional behavioral context is provided (e.g., whether the member list is live, rate limits, or authentication requirements). The description does not contradict the 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?
The description is a single concise sentence with no filler or repetition. It is front-loaded with the action and immediately conveys 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?
The tool is simple and has an output schema, but the description leaves the optional account parameter underexplained and offers no usage guidance. It is adequate for basic use but has clear gaps given the schema's lack of parameter descriptions.
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 has no descriptions (0% coverage) and the description only explains 'channel' by implication. The optional 'account' parameter is completely unexplained, leaving ambiguity about whether it refers to a network, server, or user account.
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 ('List') and the specific resource ('current members of a channel') along with the returned detail ('mode prefixes'). This distinguishes it from sibling tools like irc_list_networks or irc_whois.
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 about when to use this tool versus alternatives such as irc_whois or irc_list_conversations. There is no mention of prerequisites, exclusions, or fallback tools, leaving the agent to infer usage from the name.
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?
Annotations declare readOnlyHint=true and openWorldHint=true, which already communicate safety and scope. The description adds only the word 'current,' which is minor. It does not disclose any additional behavioral traits such as what statuses are returned, whether the account parameter is optional in practice, or any edge cases. Thus it meets the baseline but adds little beyond 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?
The description is a single, front-loaded sentence that conveys the essential purpose without any filler. Every word contributes to the meaning, making it highly concise and well-structured.
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 need not explain return values. However, it lacks information about the behavior of the 'account' parameter (e.g., what 'status' includes, whether omitting account shows global status) and offers no usage context. It is minimally adequate but leaves gaps.
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 input schema lists one parameter 'account' with no description (0% schema coverage). The description says 'IRC account,' which gives a hint about its meaning, but it does not explain whether the parameter is required, what format it expects, or what happens if omitted. Given the low schema coverage, the description fails to compensate adequately.
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: 'Show the current connection status for an IRC account.' It uses a specific verb ('show') and a distinct resource ('current connection status'), which effectively distinguishes it from sibling tools like irc_whois or irc_list_networks.
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, no prerequisites, and no exclusions. It merely states what it does. While the purpose is clear, the lack of any contextual usage information means the agent must infer when to invoke it.
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?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds the dual add/remove behavior and clarifies that the message is identified by msgid. However, it does not disclose edge cases such as reaction idempotency or permission requirements.
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 succinct sentence that front-loads the verb and resource. Every word adds value, and there is no unnecessary repetition.
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 5 parameters and no schema descriptions, this description is too brief. It fails to explain important parameters like target and account, and the output schema does not compensate for the missing parameter semantics. The description is insufficient for correct invocation in many contexts.
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?
With 0% schema description coverage, the description carries the burden of explaining parameters. It explains msgid's role and the add/remove action, but leaves target, account, and the remove flag semantics largely undefined. This incomplete guidance forces guesswork.
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 ('Add or remove'), the resource ('emoji reaction on a message'), and the identifier ('msgid'). This specific phrasing distinguishes it from sibling tools like send_message or send_raw.
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 clear context for reacting to a message, but it does not explicitly mention when to prefer this tool over alternatives like send_raw or send_message. No exclusions or alternative tool names are given.
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?
The annotations already declare destructiveHint: true, but the description adds 'cannot be undone,' emphasizing irreversibility beyond the annotation. It also clarifies that deletion is by msgid, providing additional context about the operation's scope.
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 that conveys the action and key warning without any wasted words.
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 annotations and an output schema, the description is too sparse for a destructive tool with 4 parameters. It fails to explain what 'target' refers to, how to obtain a msgid, or any permissions/prerequisites, which is critical for correct and safe invocation.
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?
With 0% schema description coverage, the description must clarify parameters. It explains that msgid identifies the message, but provides no meaning for target, reason, or account. Required parameters remain underspecified.
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 'Redact (delete) a message by its msgid,' using a specific verb and resource. This distinguishes it from sibling tools like irc_send_message or irc_react, as it is the only deletion operation.
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. The description simply defines the action without providing context or exclusions, leaving the agent to infer usage.
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?
Annotations already disclose mutating, idempotent, and non-destructive behavior. The description adds the timestamp constraint but doesn't explain side effects, permissions, or impact on other users. No contradiction with annotations; it provides minimal additional context beyond them.
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?
A single sentence with no filler, front-loading the action and scope. All words contribute to describing 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?
The tool is simple and an output schema exists, so return values are covered externally. However, missing parameter explanations and usage context make the description only minimally complete for a 3-parameter tool, relying heavily on annotations and the title.
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 references 'target' and 'timestamp' but does not define them precisely, and it completely omits the optional 'account' parameter. Timestamp format and target semantics remain unclear, leaving significant gaps.
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 ('send a read marker') and defines the scope ('up to the given timestamp for a target'). It differentiates from sibling tools like irc_send_message or irc_read_history by focusing on updating read state rather than sending or fetching messages.
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 marking a conversation read but gives no explicit guidance on when to use it versus alternatives. It doesn't mention any exclusions, prerequisites, or preference over sibling tools, leaving the agent to infer the intended context.
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?
Annotations already indicate a non-read-only, non-destructive action. The description adds no additional behavioral context beyond the optional reason, such as side effects or reversibility.
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, perfectly concise and front-loaded with the key action.
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 tool and existing output schema, the description is adequate but fails to clarify the optional 'account' parameter, which may be important for multi-server IRC setups.
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%. The description only hints at the 'reason' parameter via 'optional parting reason', leaving 'channel' and 'account' semantics unexplained.
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 action 'Leave a channel' with the optional reason. The verb-resource pair is specific and distinguishes it from sibling tools like irc_join.
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 action is self-explanatory but there is no explicit guidance on when to use it or comparison with alternatives. It does not mention prerequisites like being in the channel or that an account is needed.
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?
The description explicitly states 'Destructive and unrestricted,' which directly supplements the annotations (destructiveHint=true, openWorldHint=true) by adding a clear warning about the tool's risky nature. It also gives a safety rule about using it only as a last resort. This goes beyond the annotations' binary flags.
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, front-loaded with the core purpose, and every word earns its place. The warning and usage guidance are concise and impactful without redundancy.
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 raw IRC tool, the description covers the most critical behavioral aspects (destructive, unrestricted) and usage context. However, it omits operational details like whether the line should include CRLF, how the 'account' parameter affects behavior, and potential consequences like connection termination. The output schema exists, so return values need not be described, but the parameter semantics remain a gap.
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 has 0% description coverage, and the tool description provides no explanation for the 'line' or 'account' parameters. From the name and description, 'line' can be inferred as the raw IRC line, but 'account' is unexplained, leaving the agent to guess its purpose (likely selecting a connection). The description fails to compensate for the missing schema descriptions.
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: 'Send a raw IRC protocol line.' This specifies the verb (send), resource (raw IRC protocol line), and distinguishes it from higher-level siblings like irc_send_message by emphasizing 'raw' and 'unrestricted'.
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 usage guidance: 'use only when no higher-level tool fits.' This clearly indicates when to use the tool as a fallback and implies that alternatives should be preferred. While it doesn't name specific alternatives, the sibling list provides that context.
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?
Annotations already indicate non-read-only and non-destructive behavior. The description adds that it does not send a message and clears the typing state, but it does not address edge cases such as what happens if no typing notification is active. With annotations present, the bar is lower, and this adds moderate value.
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 only two sentences, with the main action front-loaded and no extraneous content. Every sentence adds practical 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?
For a simple tool with an output schema and existing sibling tools, the description is complete enough. It clearly differentiates from siblings and gives usage context, though the missing account parameter reduces completeness slightly.
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 0%, so the description must compensate. It gives meaning to 'target' by saying it can be a channel or user, but it does not explain the 'account' parameter at all. Thus, the description partially compensates but leaves a gap.
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 a specific verb 'clear' and a specific resource 'active typing notification', and specifies the scope ('for a channel or user'). It clearly distinguishes from sibling tools like irc_start_typing and irc_send_with_typing.
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?
Provides an explicit usage context ('if you started typing with irc_start_typing but decided not to send') and names the related sibling. It does not state when not to use, but the context is clear enough to be nearly explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: emits typing notification, delay proportional to message length, default 90 wpm, tunable wpm, and returns same response as irc_send_message. This is rich behavioral context not present in 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?
Four concise sentences, front-loaded with core purpose, then usage guidance, then return value. No redundant or filler content.
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?
Covers purpose, usage, delay behavior, and return, but with 7 parameters and no schema coverage, the missing parameter semantics and potential text/lines distinction make it incomplete. The tool is not fully self-contained for correct invocation.
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%, but description only explains wpm and implies message length. It leaves text, lines, notice, account, and in_reply_to undocumented. The 'same as irc_send_message' reference applies only to return value, not parameters, so semantic gap is significant.
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 sends an IRC message with a typing notification and delay, distinguishing it from irc_send_message. The verb 'send' and resource 'message' are explicit, and the sibling differentiation is present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this for direct conversation where a natural typing indicator is desirable' and contrasts with irc_send_message for immediate delivery. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description discloses critical behavioral details: 'ok: true means the server confirmed the send — trust it; do not re-read history to verify' and 'A failed or unconfirmed send returns an error, never an empty result.' This adds significant operational awareness not available from annotations or schema.
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 front-loaded with the core purpose and then adds necessary nuance. All six sentences serve a distinct purpose: purpose, text modes, threading, return value, trust semantics, and error behavior. There is no fluff or repetition.
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 mutating tool with six parameters and an output schema, the description covers purpose, usage patterns, threading, success/failure semantics, and follow-up actions (using msgid for reply/react/redact). It is robust enough for an agent to select and invoke the tool appropriately without additional documentation.
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 0%, so the description must compensate. It explains text vs. lines (single vs. multiline), target (channel or user), and in_reply_to (threading). However, it does not explain the 'notice' boolean or 'account' parameter, leaving some parameters underspecified. Partial compensation only.
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: 'Send a message to a channel or user.' It distinguishes from siblings like irc_send_raw (raw IRC commands) and irc_send_with_typing (typing indicator) by focusing on ordinary message sending, and it mentions threading with in_reply_to, which is a distinct capability.
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 gives clear usage context: how to provide text (single line vs. multiline array), how to thread replies using in_reply_to, and an explicit 'trust it' instruction about not re-reading history. It does not explicitly name alternative tools (e.g., irc_send_raw for raw commands), but the context and sibling list make the intended use apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, but the description goes beyond by explaining the two states (connected/idle), that idle is normal, and that connections happen automatically on first use. This adds valuable behavioral context beyond structured annotations, helping the agent interpret results correctly.
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 three sentences, front-loaded with the primary purpose. Every sentence contributes either to clarifying the output states or to preventing misinterpretation. No redundant or filler content.
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?
Given the tool's simplicity (no parameters), the read-only annotation, and the presence of an output schema, the description fully covers necessary context. It explains the meaning of each state and the auto-connect behavior, making the tool self-sufficient for correct use.
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 tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add regarding parameters. The baseline for zero-parameter tools is 4, and the description appropriately avoids irrelevant parameter details.
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 action and resource: 'List configured IRC networks.' It also provides meaningful detail about the two possible states, which helps distinguish what the tool returns. This is a specific, non-tautological description that differentiates from sibling tools like irc_list_conversations.
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 gives clear context on when to use the tool (to see networks) and provides important guidance about idle state: 'Idle is normal and not an error' and 'do not treat idle as a failure.' It does not explicitly mention alternatives or when not to use it, but the contextual instructions are sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that clients show the notification for about 6 seconds and require repeated calls to stay active. It also explains the termination path (send message or irc_stop_typing), which is valuable operational context not present in 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?
Three tight sentences: purpose, lifecycle/behavior, and alternative. No filler or tautology. Each sentence contributes essential information without redundancy.
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?
The tool is simple, has an output schema (so return values are covered), and the description gives the core action, TTL, renewal strategy, and a preferred alternative. The only minor gap is the 'account' parameter, but it is optional and likely context-dependent. Overall it's sufficiently complete for an agent to invoke correctly.
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 description clarifies the 'target' parameter as 'a channel or user', which adds meaning beyond the plain schema string type. However, the optional 'account' parameter is not explained at all, and with 0% schema coverage the description only partially compensates for the lack of parameter documentation.
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 states exactly what the tool does: 'Send a typing notification (+typing=active) to a channel or user, signalling that a message is being composed.' This uses a specific verb and resource, and mentions the protocol command. It distinguishes itself from siblings by referencing irc_stop_typing and irc_send_with_typing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: call again to keep the typing indicator alive, then send the message or call irc_stop_typing. It also names an alternative: 'For one-shot human-like sends, prefer irc_send_with_typing.' This gives clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds key behavioral context beyond the readOnlyHint/openWorldHint annotations: the buffer is live in-memory since session start, events are incremental via since_seq, and TAGMSGs are included. It aligns with openWorldHint by noting it is not complete history.
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?
Three sentences deliver a complete guide: purpose, polling pattern, and distinction from history tool. Every sentence adds value with no redundancy or irrelevant details.
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?
With an output schema present, the description sufficiently covers event types, cursor semantics, filtering, and the alternative tool. The only missing details (limit/account) are minor and do not impede correct usage.
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?
Despite 0% schema coverage, the description explains the most important parameters: since_seq as a cursor, target as channel/nick, and kinds as event filters. It does not cover limit or account, but the essential usage parameters are well documented.
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 'Return recent live IRC events' and enumerates the specific event types included. It explicitly distinguishes from irc_read_history, making its scope and purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: poll with since_seq as a cursor for new activity, filter by target/kinds, and use irc_read_history for older server-side history. This tells the agent exactly when to choose this tool over 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:

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

Score Badge

Copy to your README.md:

[![ircv3-mcp MCP server](https://glama.ai/mcp/servers/matheusfillipe/ircv3-mcp/badges/score.svg)](https://glama.ai/mcp/servers/matheusfillipe/ircv3-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/matheusfillipe/ircv3-mcp'

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