infoset-mcp

Server Quality Checklist

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

Latest release: v2.2.1
Disambiguation4/5
Most tools are distinct, with clear single vs batch and get vs list/search separations. The only potential confusion is between list_tickets and search_tickets, but their descriptions (filters vs keyword) delineate their purposes.
Naming Consistency5/5
All tool names follow the consistent pattern infoset_<verb>_<noun>, using snake_case throughout. Verbs like get, list, search, create, update, and batch_get are used predictably, and batch operations are uniformly prefixed with 'batch_get'.
Tool Count4/5
With 16 tools, the server is slightly over the typical 3-15 range, but the domain encompasses tickets, contacts, companies, emails, and SLA data, justifying the count. The batch operations add a few extra tools but serve a clear performance purpose.
Completeness4/5
Core ticket workflows (create, read, update, list, search, logs, SLA) are covered, along with contact/company read operations. Minor gaps exist such as no delete endpoints and no write operations for contacts or companies, but these do not impede primary use cases.
Average 3.4/5 across 16 of 16 tools scored. Lowest: 2.7/5.
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
- Last stable release on April 12, 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It merely restates the tool's name and provides no information about return format, sorting/pagination behavior, or any side effects. This adds no value beyond the 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 a single concise sentence, front-loaded with the key action and resource. There is no wasted information, and it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient for an agent to fully understand the tool's behavior. It does not clarify what 'activity logs' contain, despite the schema defaults for sorting and pagination.
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 descriptions cover 100% of parameters, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; it doesn't explain how sortDir or itemsPerPage affect the results.
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 'Get activity logs for an Infoset ticket' clearly states the action (get) and resource (activity logs for a ticket), distinguishing it from siblings like infoset_get_ticket. However, it does not explicitly name alternatives or elaborate on the log contents.
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 such as infoset_batch_get_ticket_logs or infoset_get_ticket. The description only states what it does without any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'List' with optional filters and pagination, omitting whether it's read-only, defaults to the logged-in user, or what the response shape is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and easy to parse, though it sacrifices depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description doesn't explain return values, default pagination behavior, or when to use the search sibling. The schema covers inputs but not operational context.
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 descriptions cover 100% of parameters with useful details such as status meanings, defaults, and format for dates. The description adds only generic 'filters and pagination,' providing marginal value 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?
Description uses specific verb 'List' and resource 'Infoset tickets', with optional filters and pagination. However, it doesn't distinguish this from sibling 'search_tickets', which also queries tickets.
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 vs. alternatives. There is no mention of when to prefer 'infoset_search_tickets' or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description is the only source of behavioral disclosure. It only says 'Update', which implies mutation, but does not state whether updates are partial or full replacement, what authentication is required, what side effects occur, or what the return value is. This is a significant gap for a mutation 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 a single, front-loaded sentence with no wasted words. It is concise, but it is also so minimal that it provides only the bare minimum. Given the tool's complexity, slightly more detail could be justified, so it's not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, the description is far too thin to provide complete context. It doesn't explain partial update semantics, required permissions, or what happens to unspecified fields. This is inadequate for a mutation tool with this complexity.
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 the baseline is 3. The description itself adds no extra meaning beyond the schema; it doesn't mention that only provided fields are updated or that ticketId is required. The schema already handles parameter semantics, so no additional credit or penalty.
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 verb 'Update' and the resource 'existing Infoset ticket', which distinguishes it from create/get/list siblings. However, it lacks scope details like which fields can be updated, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 vs alternatives. It doesn't mention that it should be used for modifying existing tickets, nor does it reference sibling tools like create_ticket or get_ticket. The usage context is completely implied.
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 disclose behavioral details such as return values, side effects, or error handling. It only repeats the core action ('Create') without adding any additional context, failing to inform the agent about the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words, making it appropriately concise and front-loaded. However, it adds little beyond the tool name, slightly reducing its informational value.
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 tool with no output schema, the description should mention expected return values or success/failure behavior. It fails to do so, and the absence of usage guidance leaves the description incomplete for an AI agent to invoke the tool correctly in context.
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 has 100% parameter description coverage, so the schema already documents all parameters. The description adds no parameter-specific information, which is acceptable given the baseline of 3 per the rubric.
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 clear verb ('Create') and resource ('Infoset ticket'), making the tool's purpose unambiguous. It distinguishes from sibling tools like list/get/update by explicitly indicating a creation 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 (e.g., update_ticket) and lacks context about prerequisites or scenarios where creation is appropriate. It only states what the tool does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden for behavioral disclosure. It only states 'List or search' and does not explicitly disclose read-only nature, pagination behavior, response format, or any other operation traits beyond the 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 a single, front-loaded sentence with no wasted words. It efficiently conveys the action and target while leaving parameter details to the schema.
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/search tool with fully described optional parameters, the description is minimally viable. However, there is no output schema and no mention of return values or pagination, and usage alternatives are absent, leaving some gaps.
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 has 100% description coverage for all three parameters (page, query, itemsPerPage), so the schema already explains their meaning. The description adds no extra parameter detail beyond the word 'search,' which aligns with the query parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List or search') and names the resource ('Infoset contacts'), making the core purpose clear. It does not explicitly differentiate from sibling tools like infoset_get_contact or infoset_batch_get_contacts, but the collection-oriented wording implies a distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that infoset_get_contact is for individual retrieval or infoset_batch_get_contacts for bulk retrieval, nor does it give any context or exclusions.
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 available, so the description carries the full burden. It only states the basic action without disclosing return format, potential errors, authentication requirements, or side effects. The read-only nature is implied by the name but not confirmed by annotations or description.
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 directly conveys the tool's purpose without any fluff or redundancy. Every word earns its place, 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 get-by-id tool, the description is minimally adequate: it states the action and the parameter. However, it lacks contextual detail about return values or behavior, and the absence of annotations makes it insufficient for full autonomy. It does not address alternatives like batch_get_companies, but that is more a usage guideline concern.
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 describes the only parameter, companyId, as 'Company ID' with 100% coverage. The description simply repeats this concept without adding constraints, examples, or format details, meeting 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 clearly states the action 'Get company information' and specifies the identifier 'by company ID'. This distinguishes it from sibling get tools like infoset_get_ticket and infoset_get_contact, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as infoset_batch_get_companies. There is no mention of prerequisites, exclusions, or contexts where another tool would be more appropriate.
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 carries the full transparency burden. It indicates a read operation ('Get') but does not disclose what 'email thread content' includes (e.g., full conversation, headers, attachments), potential failure modes, or permissions required. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. 'Get email thread content by email ID' is front-loaded and immediately clear, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (one required parameter, no output schema), the description is minimally adequate for an agent to invoke the tool correctly. However, 'thread content' is vague, and without an output schema or further detail, the agent cannot anticipate the return structure or edge cases.
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 already documents the sole parameter emailId with the description 'Email ID from ticket logs', providing 100% schema coverage. The description's 'by email ID' adds no further semantic detail, so the baseline of 3 is appropriate.
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 'Get email thread content by email ID' clearly states the verb (get), resource (email thread content), and lookup mechanism (by email ID). It distinguishes from sibling tools like infoset_get_ticket or infoset_get_ticket_logs by focusing on email threads, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an email ID is available, and the parameter description 'Email ID from ticket logs' adds helpful context. However, there is no explicit guidance on when to use this tool versus alternatives, such as infoset_get_ticket_logs, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the output ('counts by status') and does not explicitly confirm read-only behavior, describe response structure beyond counts, or mention how date ranges and ownerIds affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose while leaving details to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with three optional parameters, but no output schema exists. The description gives only minimal return information and lacks context about filtering behavior or when to use this tool. It is adequate but leaves meaningful gaps.
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 with a high coverage baseline of 3, the description need not add much. The description does not enhance or clarify parameter semantics; it only hints at overall output via 'counts by status'.
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 ('Get') and resource ('ticket statistics dashboard') and clarifies the result as 'counts by status'. It clearly distinguishes this aggregation tool from siblings like infoset_get_ticket and infoset_list_tickets.
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. It does not state that this should be used for aggregate counts rather than individual ticket retrieval, nor does it mention any prerequisites or exclusions.
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 for behavioral disclosure. It only repeats the fact that it searches by keyword, with no information about matching logic, return format, pagination behavior, read-only nature, or any side effects. This goes beyond what the name already implies, providing minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, 'Search Infoset tickets by keyword and optional filters', that is concise and free of fluff. Every word adds value, and it is appropriately sized for the tool's simplicity.
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 that there is no output schema and no annotations, the description is insufficient for a 5-parameter tool. It does not explain what the search returns, how results are matched, or any pagination behavior, leaving significant gaps for the agent to infer. The schema covers parameters, but the description lacks broader context.
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 parameters are already documented in the input schema. The description's mention of 'keyword and optional filters' summarizes the schema but adds no new meaning beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search Infoset tickets by keyword and optional filters'. It uses a specific verb ('Search') and resource ('Infoset tickets'), and the scope ('by keyword') distinguishes it from sibling tools like list_tickets and get_ticket, which likely have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the word 'Search' and the optional filters, suggesting this tool is for targeted keyword-based queries rather than simple listing. However, it does not explicitly mention when to use it over alternatives or when not to use it, so only implied guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'Get SLA breach data,' which implies a read operation but does not mention return format, potential empty results, error conditions, or any side effects. This is minimal transparency for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and target resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description covers the basic purpose but is vague about what 'SLA breach data' actually includes, which is more significant given there is no output schema to clarify return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single required parameter ticketId, which already has a description ('Ticket ID'). The tool description adds no additional parameter semantics, so the baseline score of 3 applies.
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-resource pair: 'Get SLA breach data' for an 'Infoset ticket'. This clearly distinguishes the tool from sibling tools like infoset_get_ticket and infoset_list_tickets, which target different data.
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 SLA breach data is needed for a specific ticket, but it does not provide explicit guidance on when to prefer this over siblings or any exclusions. It is a simple, implied context rather than a clear recommendation.
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 carries the full burden. It discloses that this is a read operation (get), which implies non-destructive behavior, but it doesn't mention potential 404 responses, authentication requirements, or the scope of data returned. For a simple getter, the basic 'get' is sufficient context but lacks depth.
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?
Exactly one concise sentence that front-loads the action and resource. No redundant words, every word earns its place.
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 1-parameter tool with no output schema, the description is adequate. It tells the agent what resource is being retrieved and the key. It doesn't cover return value details or error cases, but the simplicity of the tool makes it complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the contactId parameter is documented as 'Contact ID'. The description adds no new semantic meaning beyond the schema, just repeats the notion of an ID. Baseline 3 applies.
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 'Get' and identifies the resource as 'contact information' keyed by 'contact ID'. This clearly distinguishes it from sibling tools like infoset_list_contacts and infoset_batch_get_contacts, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 fetching a single contact by ID, but it provides no explicit guidance on when to use it versus alternatives like infoset_list_contacts or infoset_batch_get_contacts. There are no exclusion criteria or context cues.
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 discloses the auto-deduplication behavior, which is beyond the tool's name and adds some behavioral insight. However, with no annotations, it does not address error handling, limits, or response structure, leaving significant behavioral aspects undisclosed.
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 core purpose and includes a useful parenthetical about deduplication. There is no wasted wording.
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 one-parameter batch read, the description explains the core behavior but omits potential limits, error behavior, and how to use it relative to similar single-item tools. This leaves some gaps in context.
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 provides a complete description of the companyIds parameter (array of company IDs), and the tool description does not add additional parameter-specific semantics beyond 'auto-deduplicates,' which implicitly relates to how IDs are processed. With 100% schema coverage, the baseline of 3 is applied.
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 retrieves multiple Infoset companies in a single call, using 'get' as the verb and naming the resource. The mention of 'multiple' and 'single call' distinguishes it from the sibling infoset_get_company (singular).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching several companies at once rather than individually, but it does not explicitly reference when to prefer it over alternatives like infoset_get_company or infoset_batch_get_tickets. There is no explicit when-not or alternative guidance, so usage is only implied.
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 carry the full burden. It conveys a read-only operation ('Get') but does not discuss edge cases (e.g., missing ticket IDs, error handling, rate limits) or explicitly confirm non-destructive behavior. It adds minimal behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the key information (what it gets, for what, and the batching advantage). 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?
With no output schema, the description should clarify return format, but it only states 'Get activity logs' without describing the response shape or pagination details. The itemsPerPage parameter hints at pagination but is left to the schema. It is adequate for a simple batch read but lacks some contextual depth.
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%: both 'ticketIds' and 'itemsPerPage' have descriptions in the schema. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
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 ('Get'), the resource ('activity logs for multiple Infoset tickets'), and the batch nature ('in a single call'). It distinguishes from the sibling tool 'infoset_get_ticket_logs' by emphasizing multiple tickets and single-call efficiency.
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: use this batch variant when handling multiple tickets, versus its singular sibling. However, there is no explicit when-to-use/when-not-to-use guidance or named alternatives, so it relies on inference from the tool name and description.
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. It discloses that the tool fetches a single ticket's detail, which is the core behavior, but does not describe error handling, response contents, or any read-only guarantee. It is concise and truthful but lacks additional 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word ('Get', 'single', 'Infoset ticket detail', 'by ID') contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description is largely sufficient. It clearly indicates that a single ticket detail is returned by ID. However, it does not explicitly contrast with sibling tools that operate on tickets, leaving some selection nuance to the agent.
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 has 100% coverage, already describing 'ticketId' as 'Ticket ID'. The description does not add further meaning beyond what the schema provides, so the baseline score of 3 applies.
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 'Get single Infoset ticket detail by ID' uses a specific verb ('Get') and resource ('Infoset ticket'), and explicitly scopes it to single-ticket-by-ID retrieval. This clearly distinguishes it from siblings like infoset_list_tickets, infoset_search_tickets, and infoset_batch_get_tickets.
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 phrase 'by ID' implies the intended use case (when you have a specific ticket ID), but there is no explicit mention of when not to use this tool, such as for batch retrieval (infoset_batch_get_tickets) or listing (infoset_list_tickets). No alternatives are named in the description.
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 bears the full burden of behavioral disclosure. It does add the useful detail of 'parallel fetch', but does not mention error handling, batch size limits, or response behavior for invalid IDs, which are important for a batch operation.
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 action and resource. Every word earns its place, noting the batching behavior without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is largely complete for selection and invocation, including the batching aspect. It lacks some edge-case details like error handling, but for a straightforward batch getter, the provided context is 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 input schema already fully describes the only parameter 'ticketIds' as 'Array of ticket IDs to fetch' (100% coverage). The tool description adds no extra meaning about parameters, so it meets the baseline but does not go 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 tool fetches multiple Infoset tickets in a single call, with the verb 'Get' and resource 'tickets'. It explicitly distinguishes itself from sibling infoset_get_ticket by emphasizing 'multiple' and 'single call', making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (fetching multiple tickets at once) through the phrase 'single call (parallel fetch)', which contrasts with the single-ticket sibling. However, it does not explicitly state when not to use it or name alternatives, so it has clear context but lacks 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?
With no annotations, the description carries the transparency burden. It discloses the non-obvious auto-deduplication behavior, which is valuable. But it doesn't clarify what happens with invalid IDs, whether order is preserved, or how partial failures are handled.
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, focused sentence delivers the essential information with no redundancy. It is front-loaded and easy 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?
For a simple one-parameter batch tool with no output schema, the description covers the core purpose and one key behavior. It is sufficient for an agent to select and invoke the tool, though it could mention response format or error handling for full 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?
The schema fully documents contactIds as an array of numbers. The description adds behavioral meaning by noting auto-deduplication, which tells the agent that duplicate IDs are acceptable and will be handled—value 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 uses a specific verb-resource pair ('Get multiple Infoset contacts') and adds scope 'in a single call', clearly distinguishing it from the singular get_contact tool. The auto-deduplicates note further refines 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a single call' implies the intended use case—fetching multiple contacts efficiently—which differentiates it from repeatedly calling get_contact. However, it doesn't explicitly state when not to use it or mention alternatives like list_contacts.
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:

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

Score Badge

Copy to your README.md:

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

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