inpost-consumer-mcp

by noxlabs-ai

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: login flow tools are separate from parcel listing/detail, locker operations are distinct from tracking and returns. No two tools overlap in a way that would cause misselection; even list_parcels and get_parcel are clearly list vs. single-item operations.
Naming Consistency4/5
All tools share the 'inpost_consumer_' prefix, and most follow a verb_noun pattern (list_parcels, get_parcel, track, list_returns). However, some names are structured as noun_verb (locker_open, locker_finish) or use a domain prefix (login_send_sms, login_sessions, login_confirm), creating minor inconsistency in the verb/noun order.
Tool Count5/5
Ten tools is well within the ideal 3-15 range for a consumer-focused InPost service. Each tool covers a necessary part of the user journey—auth, parcel viewing, locker operation, tracking, and returns—without unnecessary bloat or sparseness.
Completeness4/5
The tool surface covers the core lifecycle: login, logout, session management, listing and getting parcels, opening and finishing locker sessions, tracking, and listing returns. Minor gaps exist, such as no per-return detail view or explicit support for creating a return, but these are edge cases and the essential workflows are fully supported.
Average 4.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits 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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only says 'End' and 'tear it down' without detailing side effects like whether the locker is released, whether the session is irrevocably closed, or what errors may occur. It lacks information about permissions or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action. The second sentence provides a crucial reference to the open tool without unnecessary fluff. Every word earns its place.
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?
Without an output schema, the description does not explain what the tool returns (e.g., success indicator). It also does not elaborate on the 'tear it down' scenario or the conditional phoneNumbers parameter. However, given only two params and a simple finish operation, it is minimally adequate.
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 schema already documents both parameters. The description adds a useful note that the session id comes from inpost_consumer_locker_open, reinforcing but not significantly extending schema meaning.
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 the specific verb 'End' with the resource 'Paczkomat pickup session', clearly identifying the action and scope. It also distinguishes itself from siblings by referencing the session id from inpost_consumer_locker_open, making it the explicit counterpart to the open tool.
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?
It explicitly states when to use the tool: after opening a session or for teardown. It links to the workflow by instructing to use the session id returned by inpost_consumer_locker_open. No explicit exclusions or alternatives are given, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation, lowering the bar for transparency. The description adds the optional filter behavior but does not disclose pagination, response format, or any side effects. It is consistent with annotations and provides minimal 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 two short sentences with the core action front-loaded. There is no wasted wording, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with two optional parameters and full schema coverage, the description covers the essentials. It does not mention the phoneNumbers filter or potential pagination, but these are either in the schema or low-stakes for a listing tool. Given the low complexity, the description is nearly complete.
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, describing both statuses and phoneNumbers with clarity. The description's mention of 'filter by status' is redundant and does not add meaning beyond the schema. Baseline 3 is appropriate since the schema carries the parameter semantics.
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: 'List your InPost return tickets.' The verb 'List' is specific and the resource 'return tickets' distinguishes it from sibling tools like list_parcels, which likely handles regular parcels. The optional status filter is also mentioned, providing additional scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it lists, but it does not explicitly say when to use this tool over alternatives such as list_parcels or track. No exclusionary language or alternative tool references are provided, so the guidance is implicit rather than explicit.
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?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It does disclose a side effect (saving a session on the device), which is useful. However, it does not mention failure modes, code expiration, overwriting existing sessions, or any required permissions, leaving gaps in 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 consists of two concise sentences that are front-loaded with the primary action. Every sentence adds value: the first states the core operation, and the second explains the session-saving side effect and downstream capabilities. No redundant or filler content.
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 login-confirmation tool with two well-documented parameters, the description gives a clear result (session saved) and its benefits. It lacks explicit prerequisites (e.g., must have sent the SMS first) and details about error handling, but given the simple scope and the schema coverage, it is reasonably complete.
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 provides full descriptions for both parameters (100% coverage), so the baseline is 3. The description adds no additional parameter-level meaning beyond restating that the SMS code is entered, and does not clarify formats, constraints, or relationships between the phone number and the code beyond what the schema states.
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 ('Enter the SMS code to sign in') and the consequence ('Saves your session on this device so you can list parcels and open lockers'). This distinguishes it from the sibling 'inpost_consumer_login_send_sms' and other tools by specifying the login confirmation step and its resulting capabilities.
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 after receiving an SMS code, but does not explicitly reference the prerequisite step (send_sms) or provide guidance on when not to use this tool versus alternatives like login_sessions or logout. It gives context but lacks clear exclusions or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the safe read-only nature. The description adds behavioral context by disclosing the kind of data returned (status, locker, pickup code, QR payload) and the flexibility of accepting a unique short prefix. This goes beyond the annotation without contradicting 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 sentence that front-loads the core purpose, then efficiently lists the returned details. Every part adds value, with no repetition or filler.
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 getter with 2 parameters, no output schema, and read-only annotations, the description is adequate. It covers the main purpose and key return fields. It doesn't mention error handling or exact response structure, but those are not essential for a straightforward retrieval tool.
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 coverage is 100%, with descriptions for both parameters. The tool description mentions the prefix flexibility for shipmentNumber, which is already partially in the schema ('Full shipment number or unique prefix'). It adds no significant extra parameter semantics, 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.
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 details for one parcel by shipment number'. It specifies the resource (parcel) and the identifying key (shipment number or unique short prefix), and lists the returned fields (status, locker, pickup code, QR payload). This distinguishes it from sibling tools like list_parcels or track.
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 usage context: it is for a single parcel specified by shipment number, as opposed to listing all parcels or tracking. However, it does not explicitly mention when not to use it or compare with alternatives, so it earns a 4 rather than a 5.
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?
Annotations already mark this as destructive, but the description adds valuable context: 'Anyone standing at the machine can take it' warns of the security risk, and 'Set confirm=true to proceed' clarifies the required confirmation step. This goes beyond the raw annotation by explaining real-world consequences. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each carrying essential information: action, warning, and required flag. Front-loaded with the core action, then safety, then confirmation. No wasted words or irrelevant detail.
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 and the lack of an output schema, the description covers key aspects: the action, the security risk, the required confirm flag, and a safer alternative. It is sufficiently complete for an AI agent to understand the tool's use and risk, though it could arguably mention that the opening is irreversible once triggered.
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 schema fully documents all four parameters. The description only reinforces 'confirm=true' but does not add new details about openCode or phoneNumbers. Per guidelines, baseline 3 applies when schema covers parameters; the extra mention is redundant but harmless.
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 specific verb and resource: 'Remotely open the Paczkomat compartment for a parcel.' It distinguishes this tool from siblings like 'finish' or 'track' by focusing on the physical opening action. The title 'Open locker' reinforces the purpose without ambiguity.
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 usage context: 'only use when you are there.' It also suggests an alternative behavior ('Prefer picking up in person at the correct locker') which implies a safe manual option. However, it does not explicitly mention when not to use it relative to sibling tools, so a slight gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds useful behavioral context: the scope 'on this device' and the automatic refresh of login codes when using other tools. This goes beyond the annotation by explaining session lifecycle behavior, though it does not detail edge cases like empty lists or exact return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every part adds value. The first sentence states purpose and output; the second adds a relevant behavioral note about automatic refresh. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description adequately explains what it does and what it returns (phone numbers and expiry times). It also provides session refresh context. It lacks explicit formatting details but is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema provides no parameter details. The description inherently explains the tool's scope ('on this device') and output (phone numbers and expiry times), which is the baseline expected for a parameterless tool. No additional parameter semantics are needed.
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 lists phone numbers signed in on this device and includes session expiry times. It uses a specific verb ('List') and resource ('signed-in phones') that distinguishes it from sibling tools like login_send_sms, login_confirm, and logout.
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 by stating what it does, but it does not explicitly say when to use it versus alternatives. The note about login codes refreshing when using other tools hints at session management context but does not provide direct guidance such as 'use this to check active sessions before logging in'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states what is removed (saved logins) and what is unaffected (the InPost app), which is valuable context beyond a generic 'logout.' It does not mention edge cases like behavior when no logins exist, but for this tool, the key side effects are adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the core action ('Sign out and remove saved login(s)') and then adds a single clarifying limitation ('Does not change anything in the InPost app'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logout tool with two optional parameters that are fully documented in the schema, the description provides the essential behavioral context: it is device-local and does not alter the app. No output schema exists, but the described behavior is sufficient for correct invocation. There are no significant 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 already provides full descriptions for both parameters ('Sign out every saved phone number' and 'Phone number to sign out. Omit if using all=true.'), achieving 100% schema description coverage. 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 clearly states the tool's function with specific verbs: 'Sign out and remove saved login(s) from this device.' It also differentiates from sibling tools by emphasizing the device-local scope and that it does not affect the InPost app, making it distinct from login and other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you want to sign out from this device only. It explicitly scopes the effect to 'this device' and states what it does not do ('Does not change anything in the InPost app'), which helps avoid misuse. However, it does not explicitly name alternative tools or when-not-to-use scenarios, though the sibling list makes the intended use obvious.
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?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: statuses are kept up to date with public tracking, pickup codes are included when available, and filtering is case-insensitive. This goes beyond the annotation without contradicting 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 two sentences, front-loaded with the main action, and contains no redundant or filler content. Every sentence adds meaningful information about the tool's functionality and filtering capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with two optional parameters and no output schema, the description is fairly complete. It covers what the tool returns, tracking freshness, and filter options. It could mention pagination or phone number filtering explicitly, but overall it provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra value by providing example status values, noting case insensitivity, and explaining the optional filter behavior. It does not repeat schema info verbatim and enhances understanding of the statuses 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 tool's function with a specific verb and resource: 'List your InPost parcels'. It also specifies the returned information (status, locker, pickup code) and distinguishes it from siblings like get_parcel, track, and list_returns by focusing on listing multiple parcels.
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: it lists parcels and allows optional status filtering. It does not explicitly state when to use this instead of alternatives like get_parcel or track, but the context is sufficient to infer typical use cases. Lacks explicit exclusions but gives a clear sense of purpose.
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 of behavioral disclosure. It states the key behavior: sending a one-time code via SMS, and implies a side effect (generating and sending a code). However, it does not disclose potential consequences such as rate limits, prerequisites (e.g., not already logged in), or what happens on failure. For a simple tool, the core effect is clear enough, earning a 4 rather than a 3.
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 exactly two sentences: the first states the primary action, the second mentions the following step. It is front-loaded with the key information and contains no filler. Every sentence is purposeful and adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential context: what it does and what comes next. It leverages the sibling context by referencing the confirm tool, which is crucial for an agent to orchestrate the login flow. It does not explain error handling or response format, but given the simplicity, the description is sufficiently complete. A 4 is appropriate as it exceeds minimal viability but with minor 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% for the only parameter (phoneNumber), which already includes format and example. The tool description adds no additional parameter-level information beyond what the schema provides. Therefore, the baseline score of 3 applies, as the description does not contribute extra semantic value for parameters.
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 purpose: 'Send a one-time login code by SMS to your phone.' It uses a specific verb (send) and resource (login code), and distinguishes itself from the sibling login_confirm by explicitly mentioning the next step. The title 'Send login code' aligns with the description without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Next: inpost_consumer_login_confirm with the code from the message.' This tells the agent exactly when to use this tool (initial step) and what to use next (confirm step). It effectively differentiates the tool from login_confirm and implies it is the first stage of the login flow.
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?
Annotations include readOnlyHint=true, and the description adds context beyond that by explaining authentication requirements: no login for full numbers, signed-in session for short prefixes. This clarifies potential side effects/access needs, which is valuable behavioral 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 two concise sentences, front-loaded with the main purpose and followed by a single clarifying nuance. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter, readOnlyHint, and no output schema, the description covers the essential context: what it does and how the parameter behaves. It doesn't explain the return format, but given the simplicity and annotation coverage, this is a minor gap, making the tool adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes shipmentNumber only as 'Shipment number to track', but the description enriches this by explaining that full numbers work publicly and short prefixes require signed-in context. This adds semantic meaning that goes beyond the schema, though it stops short of defining format specifics.
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 provides 'public tracking for any InPost shipment number' with a specific verb ('track') and resource ('shipment'). It also distinguishes from siblings by noting the public nature and the special short-prefix behavior, which aligns with the tool name and title.
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?
It gives clear context on when to use: for any shipment number, with full numbers requiring no login and short prefixes matched against signed-in parcels. While it doesn't explicitly name sibling alternatives like inpost_consumer_get_parcel, the description implies the tool's public scope and input handling rules, providing adequate usage guidance.
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:

[![inpost-consumer-mcp MCP server](https://glama.ai/mcp/servers/noxlabs-ai/inpost-consumer-mcp/badges/card.svg)](https://glama.ai/mcp/servers/noxlabs-ai/inpost-consumer-mcp)

Score Badge

Copy to your README.md:

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

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