GET4AGENT MARKET
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool has a clearly distinct purpose: search vs. detail, identity verification, parcel tracking, validation of various identifiers, rate lookups, and weather. No two tools overlap in functionality, making selection unambiguous.
Naming Consistency4/5Tool names are all lowercase snake_case and mostly follow a verb_noun pattern (search_listings, get_listing, verify_agent, track_parcel, validate_iin, validate_kz_iban, lei_lookup). A few are noun-only (kzt_rates, fx_rates, weather), but these are still predictable and consistent in style.
Tool Count5/5With 10 tools, the server sits comfortably in the ideal range. The number is manageable and each tool has a defined role, even if some are tangential to the marketplace theme.
Completeness2/5The marketplace surface is incomplete: it only supports searching and viewing listings, missing create, update, delete, or purchase operations. The remaining utilities (track_parcel, validate_iin, weather, etc.) form an incoherent mix with no clear workflow connecting them to the marketplace, leaving significant dead ends.
Average 3.2/5 across 10 of 10 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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.
This server has been verified by its author.
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, the description carries the full burden of behavioral disclosure. It provides no information about side effects, rate limits, data freshness, or return behavior. It is merely a noun phrase describing the data source, not what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which is concise, but it consists of a fragment rather than a complete sentence. It lacks structure and cannot be considered well-formed for the purpose of informing an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, and the description adds almost no value beyond the tool's name. It fails to explain what parameters do, what response to expect, or any usage context, making it inadequate for a tool with two undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (base, symbols) with zero description coverage. The description does not mention them at all, leaving their meaning and format completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's subject (ECB reference FX cross-rates) and source (Frankfurter), which distinguishes it from siblings like kzt_rates. However, it lacks an explicit verb like 'get' or 'retrieve', so it falls short of a fully specified purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mention that this covers ECB rates only, nor does it exclude cases where kzt_rates or other tools 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'current' rates, but gives no details about data sources, update frequency, response format, or whether the tool has any side effects. This is minimal and leaves the agent uncertain 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, which is concise. However, it sacrifices necessary substance for brevity; it does not explain the tool's functionality beyond the literal meaning of the name, so it is under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no annotations, no output schema), the description is severely incomplete. It fails to clarify the 'codes' parameter, the expected return value, or how this tool relates to the more general fx_rates, leaving the agent without enough context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'codes' is entirely undocumented in both the schema and the description. With 0% schema description coverage and no mention in the description, the agent cannot infer what values to pass or what effect the parameter has on the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: current KZT exchange rates. It distinguishes itself from the sibling tool fx_rates by currency specificity, but it lacks an explicit verb like 'gets' or 'returns', making it slightly less directive than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the more general fx_rates, nor any mention of prerequisites or alternative tools. The description simply states what it provides without contextualizing its use case.
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. It states it searches a catalog but does not disclose typical behaviors like whether it is read-only, result pagination, sorting, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise, though it lacks substantive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters, no output schema, and no annotations, the description is far too minimal. It does not explain what can be searched, how results are returned, or any context for using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about the four parameters (kind, query, category, verified_only). Since schema description coverage is 0%, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the specific resource 'GET4AGENT MARKET catalog of KYA-verified API listings'. This distinguishes it from sibling tools like get_listing, which likely retrieves a specific listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_listing. It does not mention any exclusions or preferred contexts.
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 indicates a read-only 'check' operation, but does not disclose what KYA stands for, what the response contains, whether any side effects exist, or any rate limits or auth requirements. This minimal information leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. However, it is under-specified, using the acronym 'KYA' without expansion, and lacks helpful detail that could be added without excessive length. It is adequately brief but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema and no output schema or annotations, so the description must explain return values and usage context. It does not describe what the check returns, how to interpret results, or what 'KYA' means. The description is too minimal to be considered complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for parameters, and the description does not mention 'agent_id' or explain what an agent ID is or how to obtain one. With 0% schema description coverage and no parameter context in the description, the tool's only parameter is effectively unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and the resource ('an agent's KYA / identity status'). It distinguishes this tool from all siblings, which deal with listings, parcels, validations, rates, and weather. The verb and object are specific and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for verifying an agent's identity/status, but provides no explicit guidance on when to use it versus alternatives or any exclusions. Since none of the sibling tools perform agent verification, the usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'look up' without disclosing output format, error behavior, constraints, or side effects. For a lookup tool, minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no redundant or superfluous information. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the apparent simplicity, the tool has no annotations, no output schema, and undocumented parameters. The description does not address whether q and lei can be used together, validation rules, or the return value structure, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'by LEI or name' but does not explicitly map q to name and lei to LEI, leaving the parameters ambiguous. Very little meaning is added beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'look up' with a clear resource 'global Legal Entity Identifier (GLEIF)' and indicates lookup by LEI or name. It is clearly distinct from unrelated sibling tools like search_listings and weather.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by LEI or name' implies usage context but does not provide explicit when-to-use guidance or exclusions. There are no alternatives mentioned, so usage is implied rather than explicit.
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 must disclose behavioral details. It mentions the validation algorithm but does not state what happens for invalid input (e.g., returns boolean, throws error), nor does it describe any side effects or required context. This is a significant gap for a validation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core purpose. It contains no redundant words and is well-structured for a simple validation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It fails to explain the return value or validation result semantics, and it does not cover edge cases or required preconditions. A validation tool should describe what the agent can expect as a valid or invalid result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not add parameter details beyond the name 'iban' and the inferred type 'Kazakhstan IBAN'. It does not specify expected format, length, example, or prefixes, so the agent must rely on the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Validate') and resource ('Kazakhstan IBAN'), and even names the algorithm (ISO 7064 mod-97). This distinguishes it from sibling tools like validate_iin, which targets a different identifier type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need to validate a Kazakhstan IBAN. However, there is no explicit guidance about when not to use it or how it differs from other validation tools beyond the resource name, so the context is clear but exclusions are absent.
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 burden of behavioral disclosure. It only says 'Current weather + short forecast' and 'Open-Meteo', but does not explain response format, units (metric/imperial), forecast duration, or any limitations or side effects. This is a significant gap for a tool with no structured behavioral metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence that front-loads the core functionality ('Current weather + short forecast') and the input requirement ('latitude/longitude'). Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two parameters, no output schema, no annotations). The description covers the essential purpose and input, but it omits details that would make it fully self-contained, such as forecast period, units, or data format. It is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only says 'for a latitude/longitude', which clarifies that 'lat' and 'lon' are coordinates. However, it does not specify valid ranges (e.g., -90 to 90 for lat), required formats, or units. The parameter names are self-explanatory, so the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it provides current weather plus a short forecast for a given latitude/longitude. It also names the data source (Open-Meteo), making the purpose unambiguous. Siblings are unrelated, so there is no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when weather data is needed), but it does not explicitly state usage context or mention alternatives. Since all sibling tools are clearly unrelated, the absence of explicit alternatives is not a major drawback, but the guidance is still minimal.
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 burden of explaining behavior. It mentions checksum validation and parsing but does not disclose what happens on invalid input, the return format, or whether it is read-only. This leaves critical behavioral aspects ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the purpose without extraneous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is incomplete for a validation tool. It fails to specify the return value (e.g., boolean, detailed report) or error handling behavior, leaving a significant gap in actionable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the parameter is simply a string named 'iin'. The description adds meaningful semantics by specifying 'Kazakhstan IIN/BIN' and 'checksum', which clarifies the expected format and validation logic. However, it does not detail the exact structure or parse output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a Kazakhstan IIN/BIN checksum and parses it. It uses a specific verb ('validate', 'parse') and resource ('Kazakhstan IIN / BIN'), which distinguishes it from sibling tools like validate_kz_iban.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Kazakhstani IIN/BIN identifiers by naming them explicitly, but it does not explicitly contrast with alternatives (e.g., validate_kz_iban for IBANs) or state when not to use it. The context is present but not fully elaborated.
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 burden of behavioral disclosure. It does state what data is returned (price, seller KYA status, seller DID), which is helpful. However, it does not mention error behavior, authentication requirements, or whether the result is a full response structure; for a read operation this is acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence without extraneous words. It front-loads the action ('Get full detail') and immediately lists the key fields, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 provides the main return fields and clearly scopes the operation to a single listing. It does not specify the complete response structure or error handling, but for this level of complexity the description is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does not explicitly define listing_id, but the tool name 'get_listing' and the phrase 'for one listing' make the parameter's purpose inferable. However, the description adds no specific format or constraints beyond what the parameter name implies, so it is adequate but not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource ('one listing') with a list of specific details (price, seller KYA status, seller DID). This distinguishes it from sibling tools like search_listings, which presumably return multiple listings, by focusing on retrieving full details for a single listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one listing' clearly indicates this tool is for retrieving details of a specific listing, implied by passing a listing_id. It does not explicitly name alternative tools like search_listings for searching collections, but the contextual contrast with sibling names is sufficient. No exclusions or when-not-to-use conditions are given, so it's clear but not fully 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?
No annotations exist, so the description carries the full burden. It adds useful behavioral information by stating that tracking returns status and route history and that it requires a barcode. However, it does not disclose potential error behavior, rate limits, or required authentication, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. Every word contributes to explaining the action, scope, and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description adequately conveys the core purpose and expected return. It could be more complete by mentioning limitations (e.g., only works for Kazpost barcodes) but is otherwise well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string parameter 'track' with no description. The description compensates by explaining that the parameter is a barcode, which adds meaningful semantics. While it doesn't specify format or length, for a single-parameter lookup tool this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Track'), the resource ('Kazakhstan Post (Kazpost) parcel'), and the expected output ('status + route history'). This specific verb+resource combination unambiguously distinguishes it from sibling tools, which are unrelated (listings, validation, rates, weather).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for tracking Kazpost parcels, but it does not explicitly state when to use it versus alternatives or when not to use it. No competing tracking tool appears among siblings, so the context is clear but not fully articulated.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/abay94/get4agent-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server