Pararam Nexus MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools are mostly distinct, but build_conversation_thread and get_reply_thread both retrieve threads with different methods, potentially causing confusion. Other overlaps are minor and clarified by descriptions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_group_chat, get_chat_messages). No mixing of conventions, making the surface predictable.
Tool Count5/5
20 tools is well-scoped for a messaging platform, covering creation, retrieval, editing, search, and file handling without unnecessary redundancy.
Completeness4/5
Core messaging workflows are covered, but missing update/delete chat, member management, and chat listing. Minor gaps that agents can work around.
Average 4/5 across 20 of 20 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on June 15, 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?
No annotations provided, so description carries full burden. It mentions return type and fields but doesn't disclose behavior for invalid user IDs, error cases, or that it is a read-only operation. The description is minimal on behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with the main purpose. The docstring style is clear, and every sentence adds information about args and returns. No wasted 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 tool's simplicity (1 param, no nesting, output schema exists), the description adequately covers the basic function and return fields. However, it lacks usage guidance and behavioral details, making it minimally viable but not thorough.
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 has 1 parameter (user_id) with no description (0% coverage). The description adds only 'User ID' to the parameter, which is a minimal clarification but adds no meaningful semantics beyond the schema.
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?
Clearly states verb 'get' and resource 'detailed information about a specific user'. The description lists returned fields (id, name, unique_name, team memberships), making the purpose concrete. However, it does not explicitly distinguish from sibling 'get_user_team_status', which could also return user info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'search_users' or 'get_user_team_status'. No mentions of prerequisites, context, or when not to use.
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 full burden for behavioral context. It describes parameters and return type but omits behaviors like error handling, rate limits, permission requirements, or what happens if chat_id is invalid.
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?
Structured as a docstring with Args and Returns, no fluff. Every sentence provides necessary information. Front-loaded with purpose, parameter list, and return summary.
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 essential parameters and return type given an output schema exists. Lacks situational context like error conditions, character limits on text, or idempotency guarantees. Adequate for a straightforward sending tool but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates thoroughly. It details each parameter: chat_id, text, reply_to_message_id (optional), quote_text (only used with reply_to_message_id). Adds dependency constraint and optionality beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a message to a chat' with a specific verb and resource. It distinguishes from sibling tools like create_group_chat or upload_file_to_chat by focusing on sending a plain text message to an existing chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like build_conversation_thread or reply-oriented tools. It does not explain prerequisites (e.g., user must be a member of the chat) or when to prefer it over other messaging functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the edit action and a permission constraint, but does not reveal side effects like notification, timestamp updates, or attachment handling.
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 well-structured with a clear intro and listed arguments. It is front-loaded and each sentence provides useful information.
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 no annotations and 5 parameters, the description explains parameters adequately but lacks detail on return values (though output schema exists) and error conditions or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds value by explaining each parameter's purpose (chat_id, post_no, text, quote, reply_no). This meaningfully supplements the bare schema types.
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 'Edit an existing post,' which is a specific verb and resource. It distinguishes from siblings like delete_post and send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use the tool (to edit a post) but does not explicitly compare with alternatives or state when not to use it. The constraint 'must be authored by the token's user' provides some 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?
No annotations are provided, so the description must cover behavioral traits. It discloses that it returns post numbers in server-reported order and performs a 'rerere traversal' (likely recursive). However, it does not mention potential errors, authentication needs, or side effects, leaving gaps.
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 front-loaded with a concise one-line summary followed by a clear explanation. The use of bullet points for parameters and return values improves readability, though the term 'rerere traversal' could be simplified.
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 adequately covers inputs and outputs, but lacks usage guidelines and context for when to invoke this tool. Given the presence of an output schema, return value explanation is sufficient, but missing error handling or prerequisite info limits completeness.
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?
Although the input schema has 0% description coverage, the description compensates by providing clear parameter definitions for 'chat_id' and 'post_no' in a docstring format, adding meaning beyond the schema's basic type information.
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 fetches the full reply thread rooted at a post, using server-side traversal. It distinguishes itself from sibling tool 'get_replies_to_post' by specifying it returns every transitively-reachable reply, indicating a recursive retrieval vs. direct replies.
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 contextual guidance on when to use this tool versus alternatives like 'build_conversation_thread' or 'get_replies_to_post'. It lacks any explicit conditions, prerequisites, or usage scenarios.
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?
No annotations provided; description implies a read operation but does not disclose permissions, rate limits, or other behavioral traits beyond the basic return payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose, args, returns. No unnecessary words.
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 2 required params and an output schema, the description covers inputs and outputs adequately. Lacks usage guidelines but otherwise 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?
Schema description coverage is 0%, but the description provides brief parameter descriptions ('ID of the chat', 'Post number') adding meaning over raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of attachments from a specific post, with explicit differentiation from sibling tool download_post_attachment.
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 vs alternatives like download_post_attachment or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description merely implies a read operation via 'Fetch' but does not explicitly state non-destructiveness, authorization needs, or response behavior beyond returning metadata.
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, with the core purpose in the first sentence and no wasted words. The structure is clear and directly informative.
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 (one parameter, output schema exists), the description adequately covers input, output, and purpose. Nothing critical is missing for basic 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?
The description explains that chat_id is numeric and identifies the chat, which compensates for the 0% schema description coverage. It adds meaningful context beyond the schema's type-only specification.
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 'Fetch' and resource 'a single chat's metadata by ID', making the tool's specific function unambiguous. It effectively distinguishes from sibling tools like search_chats or get_chat_messages.
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 lacks any guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or comparative context are provided.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'hydrated' PostInfo entries but does not mention read-only status, side effects, or authentication requirements. Adequate but not thorough.
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 relatively concise with clear Args and Returns sections. However, it repeats the parameter names already in the schema, which adds slight redundancy. Overall well-structured and front-loaded.
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 low complexity, presence of an output schema (though not detailed here), and no missing critical information, the description adequately covers purpose, parameters, and return type. It is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by explaining chat_id as 'Numeric chat ID' and post_no as 'Post number whose direct replies should be returned.' This significantly aids correct parameter use beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Fetch'), the resource ('direct replies to a post'), and important qualifiers ('one level deep, hydrated'). This differentiates it from siblings like get_reply_thread or build_conversation_thread.
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 the tool ('direct replies, one level deep') but does not explicitly state when not to use it or point to alternatives like build_conversation_thread for deeper threads. It provides some context but not enough to fully guide selection.
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?
No annotations provided, so description must cover behavior. It notes creation and that empty users gives an empty chat, but lacks details on permissions, side effects, or limits.
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?
Clear structure with Args and Returns sections, but could be slightly more concise. No unnecessary filler, effectively conveys necessary info.
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?
Covers all parameters and return values, given output schema exists. Missing usage guidelines but otherwise complete for a creation tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains each parameter in detail (title required, users behavior, optional description and org ID), adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a group chat with the given title and member set', specifying verb and resource. Distinguishes from siblings like create_private_chat and create_thread_chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like build_conversation_thread or create_private_chat. Usage is implied but not clarified.
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?
No annotations provided, so description carries full burden. Describes destructive action and ownership constraint, and mentions return flag. However, lacks details on permanence, error conditions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line action, then short Args and Returns. No wasted words, front-loaded.
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?
Covers core aspects: action, required params, authorship constraint, return value. Could include error handling or permanence, but adequate for a delete tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). Description adds meaning: chat_id as numeric, post_no as post number with authorship constraint. This compensates for schema gaps, but chat_id explanation is minimal.
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?
Clearly states 'Delete a post' with verb and resource. Distinguishes from sibling 'edit_post' and others. The additional ownership constraint further clarifies scope.
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?
Description implies usage (delete a post) but does not explicitly state when to use vs alternatives like 'edit_post' or when not to use. No exclusion criteria or alternative tool mentioned.
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 description adds behavioral context by mentioning the return type and specific fields (post_no, text, sender, timestamp). However, there are no annotations, and the description does not disclose auth needs, rate limits, or side effects. It implies a read operation but doesn't state it explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a clear docstring format with only necessary information. No superfluous words.
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?
With only one parameter and an output schema, the description is fairly complete. It explains the tool's purpose, the input format, and the return structure. Minor gap: no mention of error handling or authentication requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed semantics for the 'url' parameter, including an example and format, which adds significant value beyond the schema's type definition.
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 gets a specific message from a pararam.io URL, with a specific verb and resource. It distinguishes from sibling tools like get_chat_messages by the unique URL-based input.
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 an example URL but does not explicitly state when to use this tool versus alternatives like get_chat_messages or search_messages. No when-not or alternative 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?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions that the 'limit' parameter is 'applied client-side', which is a useful behavioral detail. However, it does not disclose any other traits such as authentication requirements, rate limits, or the impact of the search (e.g., whether it triggers side effects). The disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three well-structured sentences. The main purpose is front-loaded ('Search for chats by name or description'), followed by parameter descriptions and return summary. Every sentence adds value with no redundant information.
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 (2 parameters, straightforward search), the description covers the essential aspects: purpose, parameters, and return structure. The presence of an output schema reduces the need to detail return fields, but the description still provides a useful summary of the payload contents. The description is complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does: 'query' is described as a search query string, and 'limit' is explained with its default value and that it is applied client-side. This adds substantial meaning beyond the schema's bare type and default fields.
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 ('Search for chats') and the specific fields to search against ('by name or description'). This verb+resource specification differentiates it from sibling tools like 'search_messages' and 'search_users', which perform searches on different entities.
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 should be used when searching for chats, but it does not explicitly state when not to use it or provide alternative tools. The sibling tools are listed in context, but no guidance is given on when to prefer one over another. The description lacks explicit usage boundaries.
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 provided, the description carries the full burden. It discloses the search behavior, the two searchable fields, the limit parameter, and the return payload structure. It implies a read operation with no side effects, which is appropriate for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, making it easy to parse. It is not overly long, but slightly verbose for a simple search tool; however, it remains efficient.
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 an output schema exists (from context signals), the description does not need to detail returns but does so anyway, aiding completeness. For a low-complexity search tool, it covers parameters, return fields, and default behavior, though it could mention sorting or case sensitivity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It fully describes both parameters: query as 'Search query string (name or unique_name)' and limit as 'Maximum number of results to return (default: 20)', adding meaning beyond the type definitions.
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 searches for users by name or unique name, specifying the verb (search) and resource (users). It distinguishes from sibling tools like get_user_info, which likely retrieves by ID, and other search tools that target chats or 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 when needing to find users by name or unique_name, but lacks explicit guidance on when not to use it or how it compares to alternatives like get_user_info. Given the number of sibling tools, more context would help.
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 provided, the description carries the full burden of behavioral disclosure. It describes the uploading process and the two modes of providing file data, but does not mention any side effects, authentication needs, rate limits, or what happens if the chat is invalid or file already exists. The return type is mentioned, but deeper behavioral traits are absent.
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 structured with a brief opening sentence followed by a bulleted list of parameters and a returns note. It is clear and without extraneous text. Slightly more concise phrasing could be used, but overall it is efficient and front-loaded.
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 complexity (5 parameters, mutual exclusivity, optional reply-to), the description covers the essential behavior and return format. It does not discuss error cases, file size limits, or supported file types, but the presence of an output schema (per context signals) reduces the burden on the description for return value details. The description is largely complete for a file upload tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully explain each parameter. It does: chat_id, file_path, file_content, filename, and reply_to_message_id. It explains the mutual exclusivity of file_path and file_content, and the requirement for filename when file_content is set. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Upload a file to a chat,' which is a specific verb+resource combination. It distinguishes from sibling tools like send_message (for text) and download_post_attachment (for downloading). The title 'upload_file_to_chat' directly maps to the described action.
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 guidance on when to use file_path vs file_content, noting their mutual exclusivity and the filename requirement when file_content is used. It does not explicitly mention when not to use this tool compared to siblings, but the parameter explanations help the agent decide. Missing context on file size limits or format constraints.
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?
Without annotations, the description discloses the operation (create) and return value (new chat ID). However, it does not mention potential side effects or required permissions.
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: two sentences plus structured Args/Returns. It is front-loaded with the purpose and contains no extraneous information.
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 create tool with one parameter and an output schema, the description provides sufficient context: what it creates, the parameter meaning, and the return value. Minor omission of error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that user_id is the 'Numeric ID of the user to start a PM with', adding meaningful semantics beyond the schema's type-only definition, which had 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a personal (PM) chat with another user, using specific verb and resource. It distinguishes from sibling tools like create_group_chat and create_thread_chat.
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 one-on-one direct messaging via the term 'personal (PM) chat', but does not explicitly state when to use or avoid this tool compared to alternatives.
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?
No annotations are provided, so the description carries full burden. It clearly covers different behaviors (save to disk, return ImageContent for supported types, error for unsupported) and lists supported file types, but does not mention file overwrite policies or permissions.
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 well-structured with sections, bullet points for file types, and clear arg descriptions. It front-loads the core action, though could be slightly more concise.
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?
No output schema exists, but the description covers all return types (ImageContent, DownloadAttachmentResponse, DownloadAttachmentErrorResponse, error string). All parameters are explained, and supported file types are listed, making the tool self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), but the description's Args section fully explains all 4 parameters, including the purpose of output_path and that file_guid comes from get_post_attachments.
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 downloads a specific attachment from a post, with a specific verb and resource. It differentiates from siblings by explicitly covering file download behavior.
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 explains usage conditions based on output_path and file type, but does not explicitly state when not to use this tool or compare to sibling tools like get_post_attachments or upload_file_to_chat.
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?
No annotations provided, so description carries full burden. Discloses return payload includes is_member, is_admin, is_guest, and state. Implicitly a read operation with no side effects. Could be more explicit about permissions, but adequate.
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?
Description is concise with clear arg/returns sections. Could be slightly shorter but no unnecessary content. Well-structured for an AI agent to parse.
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?
With output schema present, return type is sufficiently described. No annotations, but description covers behavior and parameters. A mention that this is a read-only operation would improve completeness, but overall solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description adds meaning: user_id is the ID to check, team_id is optional and if null returns all teams. This compensates for the schema 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?
Clearly states the tool retrieves a user's team status (member, admin, guest, or not in team). Verb 'Get' and resource 'user's status in teams' are explicit. Distinguishes from sibling tools that focus on chat/message operations.
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?
Describes the optional team_id parameter: if provided, checks status in specific team; if not, returns status in all teams. Provides clear context on when to use each variant. No explicit when-not-to-use but not needed for this straightforward tool.
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 carries the burden. It extensively details search behavior (operators, filters, etc.) and the return structure, but doesn't explicitly state it's read-only or mention auth/rate limits. The behavioral detail is strong.
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 lengthy but well-structured with sections for query syntax, operators, filters, and return. It is front-loaded with purpose, but some details (e.g., all operator examples) could be condensed. Still, it earns its place.
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 complexity of search with advanced syntax and filters, the description is highly complete. It covers all parameters, behavior, and return payload. No missing aspects for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does so: query syntax with examples, limit default, chat_ids optional. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for messages across all chats or specific chats. The verb 'Search' and resource 'messages' are specific, and it distinguishes from siblings like search_chats and get_chat_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 explains how to use the tool but does not explicitly guide when to use it versus alternatives like get_chat_messages. It implies usage for broad searches but lacks when-not 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?
With no annotations, the description carries full burden. It discloses the creation action, required condition, and return value. However, it does not detail error scenarios or auth requirements, which are common for such tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then precondition, then parameter list, then return. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and an output schema, the description covers purpose, prerequisites, parameters, and return value. It lacks error handling details but is otherwise complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains each parameter in the Args section: parent_chat_id as 'ID of the chat to branch from,' post_no as 'Post number to root the branch at,' and title as 'Optional title.' This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a branch (thread) chat rooted at a specific post in another chat,' using a specific verb and resource. This distinguishes it from sibling tools like create_group_chat and create_private_chat.
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 a clear prerequisite: 'Requires the parent chat to have allow_branch=True.' It implies when to use (branching from a post) but does not explicitly mention alternatives or when not to use, leaving some ambiguity with sibling build_conversation_thread.
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?
No annotations provided, so description carries full burden. It discloses return type and pagination behavior (before_message_id). Could mention it's read-only and not destructive, but operation is clearly a fetch.
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?
Front-loaded with main purpose, then concise parameter list. Docstring format is slightly verbose but remains efficient with no redundant sentences.
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 output schema exists, description appropriately focuses on input and behavior. Covers all 3 parameters, pagination, and return content (sender, text, timestamp). No gaps for a list-messages tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description fully compensates by explaining each parameter (chat_id, limit default 50, before_message_id for pagination). Provides default values and behavior, exceeding schema information.
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?
Explicitly states 'Get messages from a specific chat,' which is a clear verb+resource combination. Distinguishes from siblings like search_messages (search across chats) and get_chat (chat info), establishing unique identity.
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?
Docstring explains parameters and pagination, implying usage when you have chat_id. Lacks explicit when-not-to-use or alternatives, but context from siblings and parameter descriptions guides selection effectively.
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?
Despite no annotations, the description fully discloses behavior: returns a flat list sorted by post_no, each post includes reply_to_post_no for tree reconstruction, and limits to recent messages via 'limit' parameter. No behavioral gaps remain.
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?
Description is well-structured with Args and Returns sections, front-loading the purpose. It is slightly verbose but every sentence adds value, earning a high score for clarity and organization.
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 has an output schema (context signal), the description explains the return payload structure adequately. No missing information for effective use; all aspects are covered including parameters, behavior, and output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explains all three parameters: chat_id, root_message_id, and limit with default. This adds meaning beyond the schema's type definitions.
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 'Build' and resource 'conversation thread', specifying it starts from a root message and recursively retrieves all replies. This distinguishes it from siblings like 'get_replies_to_post' which likely returns only direct replies.
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 explains that the tool returns all replies recursively, implying its use for full thread retrieval. It lacks explicit 'when not to use' or comparison to alternatives, but the sibling list provides context.
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:

[![pararam-nexus-mcp MCP server](https://glama.ai/mcp/servers/GaijinEntertainment/pararam-nexus-mcp/badges/card.svg)](https://glama.ai/mcp/servers/GaijinEntertainment/pararam-nexus-mcp)

Score Badge

Copy to your README.md:

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

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