sverige-begagnad-mcp

by tudorgrigoriu90

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct marketplace or supporting parameter list. The search functions are clearly separated by platform (Blocket, Tradera, Facebook, Klaravik, Vinted), and the list_* helpers are unambiguous. search_all is unique as an aggregator, so no two tools serve the same purpose.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern: list_<marketplace>_<entity> for parameter enumeration and search_<marketplace> for queries. The naming is uniformly snake_case and predictable across the entire set.
Tool Count5/5
10 tools is well within the ideal 3–15 range for a multi-source search server. Each tool has a distinct role; the list_* helpers support the search functions, and search_all adds value as a combined query. No redundant or excessive tools exist.
Completeness5/5
The server covers all major Swedish second-hand marketplaces (Blocket, Tradera, Klaravik, Vinted, plus optional Facebook) with search entry points. For each marketplace, the essential search capability is present, and helper functions for categories/locations are included where needed. The combined search_all addresses cross-platform aggregation, leaving no obvious workflow gaps.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It explicitly warns that the source is unofficial, bot-protected, fragile, and rate-limited, which is valuable transparency. It does not cover response format but that is handled by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no wasted words. Each clause adds distinct value: what it is, what it's good for, shipping scope, and reliability caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the domain, shipping, and reliability, and an output schema exists, so return values are covered. However, it fails to mention the price-filter options or any query construction details, leaving a gap in the tool's overall usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides no explanation for the query, price_min, or price_max parameters, leaving the agent without meaningful guidance beyond the property names. This is a complete gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Vinted.se, a second-hand fashion marketplace, and notes its strengths (leather/wool, branded clothing). It distinguishes from siblings by explicitly naming the source, but does not directly compare to other search tools.
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 provides useful context (good for specific items, ships anywhere, unofficial and fragile) but does not explicitly state when to use this versus alternative marketplace search tools. Exclusionary guidance is absent.
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?
Without annotations, the description discloses a key prerequisite (TRADERA_APP_ID and TRADERA_APP_KEY) and registration link, which is valuable. However, it does not describe return format, rate limits, safety, or side effects. Since it's a read-only search, some transparency is implicit, but the description could do more.
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 purpose, and includes necessary prerequisite info. Every word earns its place, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers authentication prerequisites and identifies the resource, but it lacks guidance on parameter usage, search behavior, or integration with list_* sibling tools for category/county IDs. With an output schema present, return values are not required, but the description could still be richer for a 5-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides no explanations for the 5 parameters, leaving optional filters like county_id and category_id ambiguous. The only implied param is 'query' from the tool's purpose. It does not point to sibling tools for valid ID lists, which would be helpful.
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 searches Tradera.com for second-hand listings/auctions, using a specific verb and resource. It distinguishes itself from sibling tools by naming the platform explicitly (e.g., search_blocket, search_vinted). The mention of 'official API' adds clarification.
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 context implies this tool is for searching Tradera, but it does not explicitly discuss when to use it vs alternatives. No exclusions or alternative tool references are provided, which would have elevated the score. The prerequisite mention is useful but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses that results are combined and normalized, and notes Facebook Marketplace is conditional ('if enabled'). However, it does not mention side effects, rate limits, or whether it is strictly read-only, leaving some gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the action, and contains no unnecessary words. Every sentence adds value: the first states what it does, the second states when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered. However, the tool's complexity (aggregating multiple sources with source-specific parameters) is not fully addressed. The description mentions 'combined, normalized results' but doesn't explain how filters are applied per source, which is important for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate by explaining any of the six parameters. It doesn't clarify how filters like price_max or source-specific fields (blocket_category, tradera_category_id) apply across the aggregated sources. The agent is left without guidance beyond parameter names.
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 searches multiple named sources (Blocket, Tradera, Klaravik, Vinted, and optionally Facebook Marketplace) in one call and returns combined, normalized results. This distinguishes it from sibling tools that each search a single source.
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 explicitly recommends using this tool for the 'weekly sourcing sweep' and mentions it as an alternative to calling each source separately. This gives clear usage context, though it does not explicitly state when NOT to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the behavioral traits: it's disabled by default, violates Facebook's ToS, returns an error unless configured, and points to the stub's docstring for further details. This is exemplary transparency, going far beyond a simple 'searches Facebook Marketplace'.
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 concise, using three sentences to convey the core purpose, the disabled state, and the required setup. Every sentence adds value, and the warning is front-loaded. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the tool's operational state and dependencies, which is useful for understanding its current limitations. However, it omits parameter semantics entirely, which is essential for correct invocation. Given that the output schema exists, return values are not a gap, but the parameter explanations are missing, making the description incomplete for actual use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters (query, location, radius_km) with 0% schema description coverage. The description does not mention any of these parameters or their meanings, leaving the agent entirely to guess from parameter names. No compensation is provided for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action as 'Search Facebook Marketplace', which is a specific verb+resource. However, it doesn't distinguish this from sibling search tools like search_vinted or search_tradera, relying on the name alone for differentiation.
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 strong usage context by warning that the tool is 'DISABLED BY DEFAULT', requires setting ENABLE_FACEBOOK_SEARCH=1, and implementing a stub. It also states that it returns an explanatory error otherwise. While it doesn't list alternative tools, the warnings clearly indicate when it cannot be used.
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 and does a good job by noting that prices are current bids and can rise before the auction ends, which is a key behavioral trait. It also discloses that Swedish terms work best, adding useful insight into expected interaction. It doesn't cover every aspect, but it provides meaningful context beyond a generic 'search'.
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 three sentences, each serving a distinct purpose: identifying the tool, describing the pricing behavior, and providing a language tip. It is front-loaded with the core verb and resource, with no redundant or filler 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 simple search tool with one parameter and an output schema present, the description covers the essential context: what the tool searches, when it is most useful, how prices behave, and a language tip. It lacks an explicit statement about read-only nature, but that is implied by 'search'. Overall it is nearly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, 'query', with no description. The description adds the guidance that 'Swedish search terms work best', which directly informs how to use the query parameter. However, this is a single tip and does not fully compensate for the total lack of schema-level description, so a score 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 'Search' and the specific resource 'Klaravik.se', a Swedish online auction house. It also distinguishes this tool from other marketplace searches by noting it is an auction house, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'strong for undervalued tools, machinery, and house-clearance goods.' It also offers a practical tip that Swedish search terms work best. However, it does not explicitly mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only 'list' operation and notes the output is 'valid' names, which adds some trustworthiness. But it does not disclose any potential limitations, error conditions, or additional behavioral details beyond the obvious.
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, well-structured sentence that front-loads the verb 'List' and delivers all necessary information in a compact form. 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 zero-parameter tool with an output schema, the description is complete: it states the purpose, the target use (search_blocket's locations), and the scope (valid region names). No additional context is needed to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds semantic value by explaining the output is intended for search_blocket's `locations` parameter, which is useful context beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists valid region (län) names, explicitly tying them to the `locations` argument of search_blocket(). This distinguishes it from sibling tools like list_blocket_categories and search_tradera.
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: these names are to be passed into search_blocket()'s `locations` argument, indicating when to use the tool. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Fetch' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention any rate limits or output shape. The behavior is straightforward for a simple listing tool, but the description adds minimal transparency beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that delivers the essential information: what the tool fetches and why. Every word earns its place, and it is front-loaded with the action and resource.
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?
Given the tool has no parameters and the output schema is available (so return values need not be described), the description provides complete context. It states the sole purpose (fetch category tree for IDs) and links it to the dependent tool, search_tradera(). No further information is needed for an agent to use this 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?
The tool takes no parameters, and the input schema is empty, so there are no parameter semantics to explain. The description correctly focuses on the output purpose (category_id values). With zero parameters, the baseline is 4, and the description adds sufficient context about why the tree is fetched.
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 'Fetch' and clearly identifies the resource as 'Tradera's category tree'. It further explains the purpose: 'to find category_id values for search_tradera()', which distinguishes it from sibling tools like list_blocket_categories or list_tradera_counties.
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 clearly implies when to use this tool: before calling search_tradera() to obtain category_id values. It does not explicitly name alternatives or provide when-not guidance, but the connection to search_tradera() is a strong usage signal in the context of sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read operation via 'Fetch' and explains the id->name mapping, but does not explicitly state that it is safe/read-only or describe response behavior beyond what the output schema likely covers.
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 leads with the action and resource, then provides purpose and context. Every word is purposeful; no fluff.
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?
Given the tool's simplicity (0 parameters, output schema exists), the description is fully complete: purpose, use case, and operational context are all covered in one concise sentence.
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 tool has zero parameters, so the baseline is 4. The description adds useful context about the output shape (id -> name), which compensates for the absence of parameter documentation.
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 it 'Fetch Tradera's county list (id -> name)' and explicitly ties it to search_tradera()'s optional county_id filter, distinguishing it from sibling list tools like list_tradera_categories.
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 a clear use case ('for search_tradera()'s optional county_id filter') and adds that it is 'rarely needed' because Tradera is national with shipping, giving practical guidance on when to use it without explicitly excluding alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It honestly reveals a non-obvious limitation: the location filter is by region (län) rather than a precise km radius, and it states what each result contains (coordinates/distance) so the agent can apply its own precise filtering. This is high-value transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding distinct value: purpose, location caveat, parameter guidance, and category hint. No fluff, front-loaded with the core action, and well-structured for quick scanning.
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?
The description covers the most important behavioral nuances (regional filter, fallback behavior, result contents, category helper), and an output schema exists for return values. However, it does not mention page size or pagination behavior for `max_pages`, and does not explicitly note that results may need dealer filtering, but overall it is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for any parameters (0% coverage). The description adds meaning for `locations` (regional, names from list_blocket_locations) and `category` (use list_blocket_categories), but does not explain `query` (obvious) or `max_pages` (defaults to 2). Since it covers only half the parameters and leaves the numeric control unexplained, it is useful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search Blocket.se for second-hand listings' with a specific verb and resource, clearly differentiating from sibling tools like search_tradera. It also adds the key scoping detail that the location filter is regional, not a precise radius, which helps distinguish its behavior.
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?
Provides explicit guidance to call list_blocket_categories() and list_blocket_locations() for category/location filtering, and explains the fallback behavior when locations are omitted. It does not explicitly contrast with other search tools (e.g., search_tradera), but the context is clear that this is for Blocket specifically.
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?
There are no annotations, so the description carries the burden of behavioral disclosure. It clearly states that this is a read-only operation (list), which is accurate and sufficient for a tool with no side effects. It doesn't mention pagination or return format, but those are not critical for a simple category-listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, focused sentence that says exactly what is needed and nothing more. It is front-loaded with the action and resource, making it highly scannable and efficient.
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?
Given the tool's simplicity (zero parameters, output schema present), the description is fully complete. It explains the purpose and usage context, and the output schema handles return-value details. No additional information is needed for an agent to correctly select and invoke this tool.
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 tool has zero parameters, so the description has no parameter semantics to add. Per the baseline for no params, this score is appropriate. The schema coverage is vacuously 100%, and there is nothing to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('valid category names') while also specifying the intended consumer (search_blocket's `category` argument). This distinguishes it from sibling tools like list_blocket_locations or list_tradera_categories, making the purpose immediately clear.
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 explicitly states when to use this tool: to obtain category names for passing into search_blocket(). This is a clear usage directive that naturally differentiates it from sibling list tools for other resources or markets. Even without explicit alternatives, the intended context is unambiguous.
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:

[![sverige-begagnad-mcp MCP server](https://glama.ai/mcp/servers/tudorgrigoriu90/sverige-begagnad-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tudorgrigoriu90/sverige-begagnad-mcp)

Score Badge

Copy to your README.md:

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

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