POS Support MCP Server

by Nery2004

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct: get_* for single resources, list_* for collections, and create/update/resolve for incident lifecycle. The main overlap is get_critical_incidents, which largely duplicates list_incidents with status and priority filters, though it may serve as a convenience shortcut.
Naming Consistency4/5
Tool names generally follow a verb_noun pattern with singular get_ and plural list_ prefixes, and create/update/resolve are consistent. The slight inconsistency is get_critical_incidents returning a list rather than using list_, but the naming remains readable and predictable.
Tool Count5/5
Eleven tools is well-scoped for a POS support domain, covering branch/terminal lookup, incident management, and incident search. Each tool has a clear role, and the count feels appropriate without unnecessary bloat.
Completeness4/5
The incident lifecycle is well covered with create, update, resolve, and detailed retrieval, and branch/terminal context is supported. Minor gaps exist such as no explicit cancel/reopen operation or dedicated comment/note endpoint, but agents can handle most support workflows.
Average 3.5/5 across 11 of 11 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the incident must be active and a solution is required; it omits side effects such as status changes, behavior on already-resolved incidents, idempotency, permissions, or any consequences beyond applying the solution. This is insufficient for a mutating action.
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 single sentence is short, front-loaded, and contains no filler – every word contributes to the core purpose. However, the brevity sacrifices useful detail that could be conveyed without bloating, so it is efficient rather than ideal.
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 3-parameter mutation tool with no annotations, the description is insufficiently complete. While an output schema exists, the agent lacks guidance on how resolve_incident differs from update_incident, preconditions, and parameter semantics. The description covers only the basic verb and a single requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the parameters, but it only mentions that a solution is required and applied. It does not clarify that incident_id identifies the target, what note is for, or what format/meaning solution should have. The schema provides only types and lengths, leaving the agent without semantic grounding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Resolve') and resource ('active incident') and notes a required component ('solution'), making the core action understandable. However, it does not explicitly contrast with the sibling 'update_incident' or other incident tools, so full differentiation is left to inference.
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 when-to-use or when-not-to-use guidance is given. The phrase 'active incident' implies a precondition, but the description does not mention alternatives like 'update_incident' for modifying details, nor what to do if the incident is not active. The agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool 'gets' a terminal, implying a read operation, but it does not describe what happens if the terminal is not found, any access requirements, or whether the response is a single object versus a wrapped result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one clean sentence that front-loads the action and resource, then states the two required identifiers. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are already covered. However, the description is sparse: it omits usage guidance, alternative routing, and edge-case behavior such as not-found handling. For a basic get-by-composite-key tool this is minimally viable, but there are clear gaps around when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to the parameters. It does this by explaining that terminal_code is 'branch-local,' clarifying that the key is composite and that codes are scoped per branch. This is valuable disambiguation beyond the raw schema property names, though it does not fully specify formats or constraints.
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 'Get' and the resource 'one terminal,' specifying that it retrieves a single record by two identifiers. It is distinct from list_terminals because it uses 'one' rather than 'list,' but it does not explicitly name or contrast sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool instead of siblings like list_terminals or get_branch. There is no context for when a user needs a single terminal by composite key versus a list or branch-level retrieval, and no exclusions are mentioned.
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 supplied, so the description must carry the behavioral burden. 'List' implies a read-only operation and the optional filters are mentioned, but nothing is disclosed about pagination, ordering, authorization, or failure modes. The safety profile is only inferred from 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 front-loaded sentence conveys the operation and filters with no filler. It is appropriately sized for the tool's simple signature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is enough to understand the basic list operation and optional filters, and an output schema covers return values. However, with no annotations and no usage or behavioral context, an agent still lacks guidance on pagination/ordering and how this tool relates to get_terminal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain branch_code and status. It names both filter dimensions but does not clarify what values are valid, how branch_code should be sourced, or the meaning of each status, leaving the agent to infer from the schema's enum and naming.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('terminals') and names the two optional filtering dimensions. This distinguishes it from siblings like get_terminal (single terminal retrieval) and list_branches (different resource).
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 when-to-use guidance or alternatives; it only states what the tool does and that filters are optional. It does not say to prefer get_terminal for a single terminal or explain when branch/status filtering is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that the similarity is deterministic and local, which are meaningful behavioral traits. However, it does not clarify what 'local' means, whether results are sorted, or whether this is a read-only operation, leaving important behavior unexplained.
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, tight sentence with no filler. It conveys the core mechanism and distinguishes the tool from simple incident listing, making every word earn its place.
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 search tool with four parameters and no annotations, the description is too sparse. It omits how branch_code and terminal_code scope the search, what the default limit means, how results are ranked, and when this tool should be preferred. The output schema may document the return shape, but the behavioral and usage context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only references text similarity and does not explain the query, limit, branch_code, or terminal_code parameters. The parameter names are suggestive but not descriptive, and the description adds no insight into how they affect the search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Find incidents') and resource, and adds a distinctive method ('deterministic local Jaccard text similarity') that separates it from typical listing or retrieval tools like list_incidents or get_incident. It could be stronger by explicitly naming the sibling it is not, but the core purpose is unambiguous.
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 this is for finding textually similar incidents rather than exact-match retrieval or listing, but it does not provide explicit guidance on when to choose this tool over list_incidents or get_incident. No alternative tools or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly indicates this is a mutating operation and discloses the only supported status transition, which is the most likely side effect. It does not mention permissions, reversibility, or behavior on already-resolved incidents, but the basic safety profile of a state-changing update is evident.
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?
A single front-loaded sentence with the verb and resource first; the status transition earns its place as key behavioral context. It is efficient, though it could have added a brief alternative-tool pointer without becoming bloated.
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 output schema exists and the input schema carries field constraints, the description offers enough for a basic call: edit an active incident, optionally move to in_progress, and rely on the schema for fields. It is incomplete around what 'active' means, whether resolved incidents are excluded, and how this relates to resolve_incident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to add meaning to the six parameters, but it adds none. The schema's self-explanatory names and constraints partially compensate; still, the description does not clarify distinctions like note vs description or how the optional fields interact.
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 the specific verb 'Edit' and names the resource, an incident, while constraining the action to active incidents and the status transition open to in_progress. It is clear enough to distinguish from create_incident and resolve_incident, though it does not explicitly name those siblings.
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 'active incident' and the open->in_progress transition communicate when the tool applies, but no alternative tools are named and no 'when not to use' guidance is provided. Usage must be inferred from the limited status transition rather than stated explicitly.
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 behavioral burden. It discloses that the incident is created with an 'open' status and that its scope can be branch-wide or terminal-specific, which is useful. However, it does not mention side effects, prerequisites, or what happens if terminal_code is omitted beyond relying on schema default.
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 front-loaded sentence with no redundant words; it names the action, resource, and key scoping distinction efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a 5-parameter create tool with no annotations. It omits how priority values should be chosen, how to obtain valid branch/terminal codes, and whether terminal_code absence means branch-wide. Output schema covers return shape, but input semantics remain underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only maps scope to branch_code/terminal_code via 'branch-wide or terminal-specific', leaving title, description, and priority semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Create') and resource ('support incident'), and qualifies scope as branch-wide or terminal-specific. This clearly separates it from sibling operations like update_incident, resolve_incident, and list_incidents.
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 when-to-use or when-not-to-use guidance is provided, and no alternatives are named. The verb 'Create' implies it is for new incidents, but the description does not mention checking search_similar_incidents first or explain when branch-wide vs terminal-specific should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It communicates that this is a non-destructive listing operation and that filters are optional, but it does not disclose pagination, ordering, filter-combination semantics, or what happens when no filters are supplied.
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, efficient sentence with the primary action and resource front-loaded. Every word contributes meaning, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward filtered list tool, the description covers the core action and parameters, and an output schema exists so return structure does not need to be explained. But with no annotations, it lacks guidance on default behavior, pagination, or how to choose between this and the several incident-related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It identifies the four parameters and their role as filters, which adds some meaning beyond their names. However, it does not explain matching behavior, code formats for branch_code/terminal_code, or whether filters combine; the schema's enums already cover status and priority values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('incidents'), and names the four filtering dimensions. It is clear enough to distinguish this tool from single-item tools like get_incident and semantic search like search_similar_incidents, though it does not explicitly contrast itself with any sibling.
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 this is the general-purpose tool for listing incidents, and the optional filters give context about its use. However, it provides no explicit guidance about when to prefer get_incident, search_similar_incidents, or get_critical_incidents instead.
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 behavioral burden. It discloses that the result includes a branch, an optional terminal, and ordered history, which is useful. However, it does not mention error behavior, authentication needs, or that this is a read-only operation, relying on the verb 'Get' to imply it.
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. It conveys the action, the target resource, and the key included components efficiently.
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 only one parameter and an output schema exists, the description is largely sufficient: it identifies the incident, notes the included related data, and lets the schema define the exact return shape. Minor gaps around alternative selection and error behavior remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining incident_id beyond the resource name. The single parameter is self-descriptive from its name and integer type, so this is not a critical gap, but the description adds no semantic 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?
The description clearly states the action ('Get') and resource ('an incident'), and specifies what is included: 'its branch, optional terminal, and ordered history.' This distinguishes it from list-oriented siblings, though it does not explicitly name any alternative.
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 singular 'an incident' and the required incident_id imply this is for retrieving a specific incident, but the description does not explicitly state when to choose this over get_critical_incidents, search_similar_incidents, or list_incidents. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates a read-style lookup by code, which is useful, but it omits behavior for missing or invalid codes, authorization needs, and error handling. For a simple getter this is minimally transparent 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 eight words, front-loaded with the verb and object, and contains no filler or repetition of schema details. 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 one-parameter get-by-code tool with an output schema present, the description is largely complete: it states the operation, resource, and key parameter semantics. It could add a note about not-found behavior or point to list_branches for discovering codes, but those are minor gaps.
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 provides only the parameter name, title, and minLength, with 0% description coverage. The description adds meaningful semantics by explaining that branch_code is a 'stable business code,' distinguishing it from an internal ID or arbitrary label. It lacks format examples, but for a single required parameter this is sufficient.
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 and resource ('Get one branch') and clearly distinguishes itself from list-oriented siblings like list_branches by specifying a single object lookup. The qualifier 'by its stable business code' adds concrete selection semantics.
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 this tool is for retrieving a single branch when you already have a stable business code, but it never explicitly names an alternative such as list_branches for browsing branches. It gives no when-not-to-use guidance, so usage is only implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation and the optional status filter communicates the main behavioral variation. However, it does not mention pagination, ordering, data scope ('fictitious'), or any other behavioral details that would help an agent understand the call outcome 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 redundant words. It states the core action first and adds the optional filtering condition second. 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 simple list tool with one optional parameter and an output schema present, the description is largely sufficient. The only notable gap is the lack of explicit guidance about sibling tools, but the low complexity and schema coverage keep the tool invocable without more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining that 'status' acts as an optional filter, which is meaningful semantic information beyond the raw schema property definition. The enum values are already present in the schema, so the description's contribution is appropriate for the single 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 the action ('List'), the resource ('fictitious branches'), and the optional scoping mechanism ('filtered by status'). This distinguishes it from sibling tools like get_branch (singular retrieval) and list_terminals/list_incidents (different resources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: whenever a list of branches is needed, with status as an optional filter. It does not explicitly name excluded alternatives or say 'use get_branch for a single branch', but the resource scope is evident 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.
Behavior4/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 the core filtering behavior (unresolved, critical, optional branch scope) and the verb 'List' implies a read-only, non-destructive operation. It does not mention pagination, sorting, or behavior when branch_code is omitted, but these are minor for a simple list tool and covered by the output 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?
One concise sentence, front-loaded with the action and resource, followed by the qualifier. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one optional parameter and an output schema. The description covers the tool's purpose and the branch filter; the schema documents the parameter; the output schema documents return values. For a list operation, this is sufficient information for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. The phrase 'optionally for one branch' tells the agent that branch_code is a filter that narrows to a single branch and that omitting it returns all branches (matching the schema default null). This adds meaning beyond the raw schema type, though it does not detail accepted value formats.
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 action ('List') on a specific resource ('unresolved critical incidents') with an optional branch filter. This distinguishes it from siblings like list_incidents (general list) and get_incident (single item).
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?
Usage is implied: the description indicates it is for unresolved critical incidents and optionally a specific branch, but it never explicitly names list_incidents as the alternative for other incident types or states when not to use this tool. With a sibling named list_incidents, explicit routing would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

POS Support MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![POS Support MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Nery2004/pos-support-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Nery2004/pos-support-mcp-server)

Score Badge

Copy to your README.md:

[![POS Support MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Nery2004/pos-support-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Nery2004/pos-support-mcp-server)

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/Nery2004/pos-support-mcp-server'

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