Search classified listings on Malinica, a Serbian free serbian classifieds marketplace.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: category catalog vs. category details vs. listing retrieval vs. picklist values vs. searching listings vs. searching locations. There is no overlap between any of the six tools.
All tool names follow a consistent snake_case verb_noun pattern: get_ for retrieval (categories, category, listing, picklist_values) and search_ for search operations (listings, locations). This is predictable and easy to reason about.
Six tools is well-scoped for a read-only classified listings API. Each tool covers a distinct aspect of the discovery and retrieval workflow with no redundancy or bloat.
The core read operations are covered, but there is a notable gap: get_category documents attributes that listings can be filtered by, yet search_listings only accepts free text, category, and location – attribute filters are missing. Also, search results are non-paginated, which can limit usability. Workarounds exist (using q to match attribute values), but the surface is not fully coherent.
get_categoriesget_categoriesAList every active listing category as a flat catalog. Each entry has a numeric id, a dot-separated path encoding its place in the hierarchy (for example vozila.automobili is a child of vozila), and a human-readable title in Serbian. Call this first to translate what a user is looking for into a category id, then call get_category to learn which attributes that category supports.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds valuable behavioral context: it returns 'every active listing category' in a flat structure, including numeric ids, dot-separated paths, and Serbian titles, which the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: stating the operation, detailing the output structure, and providing workflow guidance. The core action is front-loaded in the first sentence, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description fully carries the informational burden. It explains every field returned, the meaning of the dot-separated path, and how to use the result in a multi-step flow. An agent can call this tool and interpret the response correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description has no parameter details to add. The schema already covers everything (vacuously), and the description implicitly confirms that the tool takes no input by focusing entirely on the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the explicit verb 'List' with the resource 'active listing category' and characterizes the result as a 'flat catalog'. It clearly differentiates itself from get_category by explaining that get_categories provides the category id while get_category covers attribute support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Call this first' to convert user intent into a category id, then call get_category for attributes. It not only states when to use the tool but also names the next step and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_categoryget_categoryADescribe one category and the attributes listings in it can be filtered by. Each attribute has a name (the key to use when filtering), a label, and a type giving the JSON value a filter must supply: string, number, boolean or date (ISO 8601). An attribute may also carry options, which are the only accepted values for it; value_type with min and max, bounding what numbers are accepted; or a picklist_path, whose accepted values are not listed here and must be fetched with get_picklist_values. A picklist_depends_on names another attribute whose value narrows this one.
| Name | Required | Description | Default |
|---|---|---|---|
| categoryId | Yes | Numeric category id, as returned by get_categories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, and the description aligns with these. It goes beyond annotations by detailing attribute structure, accepted value types, options restriction, numeric bounds, picklist paths, and dependency behavior, which are important for correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with the main purpose and then efficiently explains the attribute contract with necessary detail. It is somewhat dense, but every clause earns its place and avoids filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no output schema, the description fully explains what the response contains and how to interpret each attribute field. It even routes to get_picklist_values for values not listed inline. Nothing essential is missing for an agent to call and consume the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter fully with a clear description ('Numeric category id, as returned by get_categories'), so the description does not need to repeat parameter details. It adds no extra parameter semantics, but the schema is already sufficient, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Describe') and a specific resource ('one category'), with a distinctive focus on filter attributes. This clearly differentiates it from get_categories, which presumably lists categories, without needing to rely on the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is the way to obtain category-specific filter attributes and gives clear guidance that picklist_path values must be fetched with get_picklist_values. It does not explicitly state exclusions or when to prefer other siblings, but the context and the explicit reference to get_picklist_values provide practical routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_listingget_listingAFetch one published listing by id, including its full description, price, location, category and stored attribute values. Attribute keys match the names reported by get_category for that listing's category, and attributes holds the raw stored values. Under the same key, attribute_labels gives that attribute's display label, plus a value label where the value comes from a fixed set such as a picklist or enum — use the labels when describing the listing to a user, and the raw values when filtering. Only public listings can be fetched.
| Name | Required | Description | Default |
|---|---|---|---|
| listingId | Yes | Numeric listing id, as returned by search_listings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and idempotent traits with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond this by explaining the data model quirk: attribute_keys are shared with get_category, and attribute_labels contains display vs raw values, which is important for correct downstream formatting. The explicit 'Only public listings can be fetched' discloses a major behavioral limitation not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each one carrying meaningful information: the core purpose, the attribute-key relationship, the raw-vs-label distinction for presentation, and the public-only restriction. Though a bit longer than minimal, there is no filler—every paragraph earns its place. It maintains a logical flow from purpose to details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description does the heavy lifting of communicating the response contents (description, price, location, category, attributes, labels). It also clarifies the critical relationship with get_category, which helps the agent understand attribute keys. It stops short of fully specifying the response shape or error behavior for private/not-found listings, which a more complete description would include.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter, listingId, and schema description coverage at 100%, the schema already fully documents the parameter ('Numeric listing id, as returned by search_listings'). The tool description doesn't add anything of additional semantic value beyond repeating that it is a listing ID. Following the baseline rule for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource operation 'Fetch one published listing by id' and enumerates the included data fields (description, price, location, category, attributes). This clearly distinguishes it from siblings: search_listings returns multiple listings, get_category returns category metadata, and get_category_names returns category names. An agent can categorize the tool without inspecting other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates the tool's scope (single listing lookup by ID) and a key constraint ('Only public listings can be fetched'), which implies when the tool would be invalid (private listings). However, it does not explicitly mention when to use search_listings instead (e.g., when searching without an ID) or when additional attribute context would require get_category. These exclusions are not explicit enough for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_picklist_valuesget_picklist_valuesAList the accepted values for an attribute whose get_category entry carries a picklist_path. These value sets are hierarchical and too large to inline, so they are fetched one level at a time. A picklist_path may contain a placeholder in braces naming another attribute, as in 'vehicles.car.{make}'; replace the placeholder with that attribute's chosen value before calling, so picking make 'toyota' means requesting 'vehicles.car.toyota' to get the models for it.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Fully resolved dot-separated picklist path, with any placeholder already substituted |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: picklist value sets are hierarchical and fetched one level at a time, and placeholders in the path must be resolved before calling. This helps the agent understand the tool's behavior beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. The first sentence states the core purpose, the second explains the hierarchical nature and one-level-at-a-time retrieval, and the third gives a concrete placeholder example. Every sentence contributes necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, idempotent), the description covers the essential operational details: when to call it, how the path works, placeholder substitution, and the hierarchical one-level-at-a-time behavior. It does not describe the return shape, but this is somewhat mitigated by the lack of an output schema and the straightforward nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the path parameter at 100%, describing it as a 'Fully resolved dot-separated picklist path, with any placeholder already substituted.' The description adds further meaning with a concrete example ('vehicles.car.{make}' → 'vehicles.car.toyota'), clarifying how to construct the path and why substitution matters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List the accepted values for an attribute whose get_category entry carries a picklist_path.' It clearly distinguishes this from the sibling category and listing tools by focusing on picklist value enumeration rather than category retrieval, listing retrieval, or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when an attribute's get_category entry includes a picklist_path. It also explains the practical workflow, including that paths are hierarchical and fetched one level at a time. It does not name alternatives explicitly or state when not to use it, but the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_listingssearch_listingsASearch published listings by free text, category and location. Every argument is optional but at least one must be given; supplying several narrows the result the way a user ticking filters would.
category_id and location_id are hierarchical and match the whole subtree beneath them, so the category 'Mobilni telefoni i oprema' also returns listings filed under its child categories, and Beograd also returns listings in Novi Beograd, Zemun and every other place under it. Filter at the broadest level the user actually meant, and only narrow when they named a specific place or category. Get ids from get_categories and search_locations.
q is an ordinary keyword search, not semantic or vector search: it matches words the listing actually contains, so synonyms and paraphrases will not find anything. It matches broadly across titles, descriptions, attribute values and the listing's category and location names, but ranks titles and descriptions highest. Prefer q for what an item is, and the id filters for where it is and what it is filed under — 'stan Beograd' works, but a location_id for Beograd works better.
Only the first few best matches are returned and there is no way to page past them. If the result looks too broad, narrow the search and call again rather than asking for more.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keywords to match, for example 'iphone 15 pro' | |
| limit | No | Maximum results to return (1-10, default 10) | |
| categoryId | No | Numeric category id from get_categories; matches this category and everything under it | |
| locationId | No | Numeric location id from search_locations; matches this place and everything under it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals critical behavioral traits: hierarchical subtree matching for category and location, the keyword-based (not semantic) nature of q, and the no-pagination limitation ('Only the first few best matches are returned'). This adds substantial context that annotations alone do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-paragraph structure front-loads the core function and follows with behavioral details and limitations. It's dense but every sentence adds value; slightly long, though justified given the tool's idiosyncrasies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could detail return values but instead smartly explains the key limitation (no pagination) and recovery strategy. It covers parameter behavior, hierarchies, and edge cases. Not describing the result fields is a minor gap that can be inferred from search results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description goes far beyond: it clarifies that categoryId/locationId match subtrees, explains that q matches across titles/descriptions/attribute values with title/description ranking highest, and warns that synonyms won't match. These are semantic details missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search published listings by free text, category and location,' clearly stating the tool's function. It doesn't explicitly name sibling tools for differentiation, but the clear scope and the mention of companion tools for ids make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use filters ('Filter at the broadest level the user actually meant'), explains parameter trade-offs ('Prefer q for what an item is, and the id filters for where it is'), and points to companion tools ('Get ids from get_categories and search_locations'). This is explicit when/when-not guidance that an agent can act on directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_locationssearch_locationsAFind Serbian locations by name and return their numeric ids, which is how listings are filtered by place. Matching is fuzzy and tolerates missing diacritics. Results carry a level (COUNTRY, MUNICIPALITY, CITY, CITY_MUNICIPALITY, SETTLEMENT, NEIGHBOURHOOD) and a path showing where the place sits in the hierarchy; use both to pick between same-named places, and prefer asking the user rather than guessing when several look plausible.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (1-25, default 10) | |
| query | Yes | Place name to search for, for example 'Novi Sad' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: matching is fuzzy, missing diacritics are tolerated, results include level and hierarchy path, and results can contain multiple same-named places. This informs agent expectations about output quality and ambiguity in ways annotations cannot. There is no contradiction with readOnlyHint or idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense: it states purpose, core matching behavior, result features, and decision guidance in a few sentences. Every clause earns its place, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter lookup tool with no output schema, the description is complete. It covers what the tool returns, key caveats, disambiguation fields, and an action policy for uncertain matches. The behavioral risks are clearly disclosed despite the safety annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is a 3. The description adds value by explaining that the returned ids are the mechanism for location-based filtering and that results include hierarchy context for disambiguation. It doesn't add much detail about the limit parameter, but that is already documented adequately in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Find Serbian locations by name and return their numeric ids'. It further distinguishes itself from siblings by noting that listing filtering relies on these ids, making its role distinct from search_listings and listing retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates where this tool fits: it is for finding locations used in listing filters, with fuzzy matching and diacritic tolerance. It gives practical guidance for disambiguating results using level and path, and explicitly advises asking the user rather than guessing. It does not explicitly name sibling search_listings as an alternative, but the context makes the boundary understandable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!