@theyahia/jivosite-mcp

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation3/5
Most tools target distinct resources (chats, agents, contacts, webhooks), but get_chats and skill_active_chats overlap in purpose (both deal with active chats), and get_agents and skill_agent_stats have overlapping focus on agents. The 'skill_' tools appear to provide summaries that could be confused with the base getter tools, though descriptions help differentiate them.
Naming Consistency3/5
The majority of tools follow a consistent verb_noun pattern (get_chats, create_contact, send_message, etc.). However, two tools have a 'skill_' prefix (skill_active_chats, skill_agent_stats), which deviates from the established pattern and introduces a mixed convention.
Tool Count5/5
With 11 tools, the set is well-scoped for a JivoSite integration. Each tool serves a clear purpose in managing chats, contacts, agents, and webhooks, fitting comfortably within the typical 3-15 range without feeling sparse or bloated.
Completeness4/5
The surface covers core operations: listing and messaging chats, managing contacts (get/create but no update/delete), retrieving agents, and CRUD for webhooks (get/create/delete but no update). Minor gaps exist (e.g., no chat close/assign, no contact update) but agents can likely work around them for common workflows.
Average 3.4/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'delete' but does not mention irreversibility, required permissions, side effects, or error behavior. For a destructive operation, this is insufficient.
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, clear sentence with no redundancy. It is concise and front-loads the action, though it omits useful context. Being appropriately sized for a simple tool, it earns a 4 rather than a lower score for being too terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no annotations and no output schema, the description should disclose consequences like permanence or prerequisites. It does none of these. The schema covers the parameter, but the description lacks key context an agent needs to use it safely and 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 input schema fully describes the only parameter (webhook_id) with its own description. Since schema coverage is 100%, the description adds no additional meaning, but the baseline of 3 is appropriate. The description does not compensate 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 the action (delete) and the resource (webhook), and it distinguishes the tool from siblings like get_webhooks and create_webhook by the action verb. Even though it's short, it unambiguously communicates its purpose.
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 its siblings. It does not mention prerequisites, context, or exclusions. The description leaves the agent to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says it returns a summary of active chats. It does not state whether this is a read-only operation, how fresh the data is, whether it requires special permissions, or what form the summary takes (e.g., counts, group-by-agent). This is thin disclosure for a tool with zero structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. It is not verbose and every word contributes. It could be slightly more detailed, but for a zero-parameter tool it is efficiently 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?
Given the tool has no parameters and no output schema, the description gives a basic idea of what it returns (a summary of active chats). However, it does not specify the exact content of that summary, such as whether it includes operator names, chat counts, durations, or any time-window constraints. For an agent to confidently interpret results, more detail on the output format would be helpful, but it is not completely inadequate.
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?
There are zero parameters, so the schema is empty and no additional parameter explanation is needed. The description does not need to add parameter semantics. The baseline of 4 applies because the tool takes no inputs, leaving nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a summary of current active chats with operators, using a specific verb ('provide summary') and resource ('active chats'). It distinguishes itself from sibling get_chats by qualifying 'active' and 'summary', though it does not explicitly name the sibling. That is enough to establish core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus get_chats or others. There is no mention of context, prerequisites, or exclusions. An agent must infer from the name and description alone, which is insufficient for selecting between similar chat-list tools.
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 provided, the description bears the full burden of behavioral disclosure. It only states the action without revealing side effects, validation rules, authentication requirements, idempotency, or what happens on duplicate creates. The description is not misleading, but it adds no behavioral context beyond the name.
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 that immediately states the action and subject with zero superfluous words. It is well-structured for rapid agent parsing and follows a front-loaded pattern, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, the description lacks critical context such as expected return values, error handling, and duplicate-contact behavior. While the schema covers parameters, the tool's behavioral context is under-specified, leaving an agent unable to predict the outcome or handle failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all four parameters with 100% coverage, providing complete definitions for name, email, phone, and description. The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Создать новый контакт в JivoSite' (Create a new contact in JivoSite), which is a specific verb-resource pair with a clear platform context. It unambiguously distinguishes the tool from read-only siblings like get_contacts and send_message by declaring a create action.
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 such as get_contacts or send_message. It does not mention any prerequisites, exclusions, or scenarios where another tool would be preferred, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. As a mutation tool, it only says 'create webhook' without mentioning side effects, auth requirements, error conditions, or success handling. This is a significant gap for an operation that creates a resource.
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 redundant words. It front-loads the action ('Создать') and purpose ('для получения событий'), efficiently conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description states the core function, it lacks essential context for a mutation tool: it doesn't explain what the webhook is used for beyond receiving events, what the response contains (no output schema exists), or any operational caveats. For a tool with no annotations and no output schema, this is inadequate.
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?
Both parameters (url and event) are fully described in the input schema, including format (uri) and enumerated event values. The description adds no extra meaning beyond the schema, so it meets the baseline for high schema 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 states the specific verb 'Создать' (create) on the resource 'вебхук JivoSite' (JivoSite webhook) with the purpose 'для получения событий' (for receiving events). This clearly distinguishes it from sibling tools like get_webhooks and delete_webhook.
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 explicit guidance is provided about when to use this tool versus alternatives. The description only states the action, not the context or conditions under which it should be chosen over get_webhooks or delete_webhook, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'get messages,' which implies a read operation, but does not mention pagination, ordering, size limits, or potential errors. The existence of limit and offset parameters in the schema hints at pagination, but the description itself adds no behavioral context beyond the verb.
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, clear sentence that states the purpose without fluff. It is front-loaded with the action and resource, and is appropriately sized – no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, an output schema, and the presence of pagination parameters, the description is incomplete. It does not explain the return format (e.g., array of messages), any constraints like maximum message count, or the behavior when no messages exist. An agent cannot fully predict the tool's response or edge cases from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description (chat_id, limit, offset). The description adds no extra meaning beyond what the schema already provides. It correctly implies that messages are fetched for a specific chat, but does not enrich the semantics of limit or offset. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 a specific verb and resource: 'get messages from a JivoSite chat by chat_id'. It clearly distinguishes from sibling tools like get_chats (list chats) and send_message (send a message), leaving no ambiguity about what this tool does.
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. The description does not mention conditions like when to use get_chats instead, or any prerequisites (e.g., chat existence). The only hint is the parameter name chat_id, but no explicit context is given.
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 provided, the description must fully disclose behavior. It states the tool returns online/offline status and a summary, implying a read operation, but does not explicitly declare that it makes no modifications, requires no authentication, or what the exact output format is. This lack of explicit behavioral disclosure is a gap.
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 that front-loads the tool's purpose with specific details. No wasted words or redundant 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?
Given the tool's simplicity (no parameters, no output schema), the description provides minimal but adequate context for a stats tool. However, it does not describe the exact structure of the summary or whether the data is real-time, leaving some ambiguity in how to interpret results.
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 an empty schema, so there is nothing to explain. Baseline for 0 parameters is 4, and the description adds no parameter information because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides operator statistics, specifying who is online, who is offline, and an overall summary. This distinguishes it from sibling tools like get_agents, which likely list agents, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or recommended scenarios, leaving the agent to infer from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'send' which implies a mutation, but it does not describe any side effects, authentication requirements, rate limits, or what happens on success/failure. For a write operation without annotation support, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no filler. The core action is immediately clear, and every word contributes to the purpose. It is optimally concise and front-loaded.
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 is a simple send operation with three simple parameters and no output schema, the description covers the basic intent. However, it lacks any mention of prerequisites (like obtaining chat_id from get_chats), error handling, or response behavior, which would be expected given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (body, type, chat_id) are already documented in the schema. The description adds no additional meaning or context beyond what the schema provides, matching the baseline of 3 for high 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 uses a specific verb ('Отправить' = send) and resource ('сообщение в чат' = message to a chat), which clearly states the action and target. It distinguishes this tool from sibling read operations like get_messages and get_chats, so an agent can infer its purpose without opening the schema.
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 you need to send a message, use this tool. However, it does not explicitly mention when not to use it or provide alternatives, nor does it reference related tools like get_chats to obtain the required chat_id. The context is clear but lacks explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'get a list of agents' without mentioning pagination, sorting, limits beyond the schema, or any side effects. It doesn't state that it is read-only or describe how the limit parameter affects results. The description adds minimal value beyond the tool name and 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 one short sentence with no redundant words. It is front-loaded and conveys the essential purpose immediately. No fluff or irrelevant details.
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 read-only list tool with one optional parameter and no output schema, the description is sufficiently complete. It states what is returned (list of agents). No additional context (e.g., authentication, rate limits) is strictly necessary given the simplicity, though it could mention default behavior of limit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter (limit). The description does not add any extra meaning about the parameter beyond what the schema provides. Baseline of 3 is appropriate since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('get') on a specific resource ('list of agents') and clarifies that agents are operators in JivoSite. This distinguishes it from sibling tools like get_chats or get_contacts without ambiguity. The verb-resource combination is explicit and matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving agents, but it does not explicitly mention when to use it over alternatives or provide any exclusion criteria. Sibling tools are inherently different (chats, contacts, messages), so context is clear, but there is no explicit usage guidance beyond the purpose statement.
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 is the only source of behavioral information. It states that it returns a list and supports search, which is clear. It does not disclose pagination behavior (though limit/offset are in the schema), response format, or potential side effects (none expected). For a read-only list tool, this is adequate but not rich.
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 short sentence, front-loading the primary action and resource. It includes the key search functionality without any filler. Every word contributes to the meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is adequate. It mentions the resource and search capability. However, there is no output schema, and the description does not hint at the structure of the returned contacts or any unusual constraints. For a straightforward GET operation, this is minimal but sufficient.
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 schema already provides descriptions for all three parameters (limit, query, offset), and the coverage is 100%. The description adds minimal value by restating the search capability ('search by name, email, phone'), which echoes the query parameter description. No new parameter-level information is introduced.
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 identifies the resource (JivoSite contacts) and the verb (get a list). It also specifies the supported search criteria (name, email, phone), which distinguishes it from sibling tools like get_chats or get_agents. The purpose is unambiguous and specific.
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 usage context is implied by the resource name and description: it is for retrieving contacts. However, there is no explicit guidance on when to prefer this over other tools, nor any mention of filtering options or prerequisites. The description is sufficient for an obvious list tool but lacks explicit alternative routing.
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 convey safety and behavior. It states it's a 'Получить' (get) operation, implying read-only, but does not disclose any rate limits, authentication needs, or potential side effects. For a read tool, this is acceptable but not comprehensive.
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 one concise sentence that front-loads the main purpose and the status filter. No unnecessary 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 list tool with fully documented parameters and no output schema, the description is adequate. It covers the essential purpose and filter capability. It doesn't mention return format, but that is not critical for a standard list operation.
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 schema describes all three parameters (limit, offset, status) with clear descriptions, so the schema carries the heavy lifting. The description redundantly mentions the status filter but does not add additional meaning beyond the schema. Baseline 3 applies due to 100% schema 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 states a clear verb ('Получить' = get) and resource ('список чатов' = list of chats). It differentiates from siblings like get_agents and get_contacts by the resource type. The filter by status adds specificity.
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 retrieving chats with optional status filtering, but it does not provide explicit guidance on when to use this tool instead of others, nor does it mention any alternatives. Context is clear but not explicit about exclusions.
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. It discloses that the tool retrieves a list of webhooks, which implies a read-only operation. However, it does not mention any potential side effects, authorization requirements, or rate limits. For a simple, parameterless read, this is adequate but not rich.
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 in Russian that conveys the complete action. It is front-loaded with the verb and resource, contains no filler, and every word earns its place. This is exemplary conciseness for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a straightforward purpose, the description sufficiently communicates that it returns a list of webhooks ('список вебхуков' implies a list result). There are no complex behaviors or hidden requirements. Slightly more detail about the structure of the returned list could be added, but the description is complete enough for a tool of this simplicity.
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, so the description does not need to clarify parameter meanings. The baseline for zero parameters is 4. The description adds no parameter-specific information, but none is required. The schema is empty, so there is nothing to compensate for.
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 a specific verb ('Получить' = get) and a specific resource ('список вебхуков' = list of webhooks). It clearly distinguishes from sibling tools like create_webhook and delete_webhook by signaling a read operation. The purpose is unambiguous and immediately actionable.
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 does not explicitly state when to use this tool versus alternatives, but the purpose itself implies usage: to retrieve existing webhooks. There is no mention of prerequisites or when to prefer it, which is a minor gap. The context of the sibling tools (create/delete) makes the use case obvious, so this is acceptable but not explicit.
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:

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

Score Badge

Copy to your README.md:

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

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