Information about all flea-markets (loppemarked) in Norway. Search, filter by area, date. Read guides and tips.
Each tool has a clearly distinct purpose: search_events/search_articles handle listing and search, get_event/get_article retrieve single-item details, and create_event_tip is explicitly a review-queue submission rather than direct publishing. There is no meaningful overlap or ambiguity between tools.
All tool names follow a consistent snake_case verb_noun pattern: search_* for search/list operations, get_* for detail retrieval, and create_event_tip for the submission action. The naming is uniform and predictable.
Five tools is well-scoped for a public read/search platform with a single anonymous contribution path. Each tool covers a necessary operation without redundancy or bloat.
The tool surface covers the full public-facing workflow: search and retrieve both events and articles, plus submit new event tips for admin review. Since tips are anonymous and admin-moderated, update/delete or status-tracking tools are not expected, so there are no obvious gaps.
Submit a tip about a flea market event discovered from an external source such as a website, Facebook post, or local notice. The tip is NOT immediately published — it enters a manual review queue for Svapp administrators who verify and publish it. Use this when you find event information that does not yet appear in the Svapp database. The tip is anonymous and not associated with any Svapp user or organisation. Include as much detail as possible (dates, location, contact info, delivery dates, source URL) to help administrators process the tip quickly. For date fields, prefer 'yyyy-MM-dd'. For time fields, prefer 24-hour 'HH:mm' or 'HH:mm:ss'. Example date entry: { "date": "2025-09-14", "startTime": "10:00", "endTime": "16:00" }.
| Name | Required | Description | Default |
|---|---|---|---|
| dto | Yes | Full event tip payload. Provide all known details; the more complete, the faster it can be reviewed and published. Date format: 'yyyy-MM-dd'. Time format: 'HH:mm' or 'HH:mm:ss'. Example Dates item: { "date": "2025-09-14", "startTime": "10:00", "endTime": "16:00" }. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behavior: the tip is NOT immediately published, enters a manual review queue, and is anonymous/unassociated with any user or organization. It does not mention response behavior or auth requirements, but the most decision-relevant traits are covered.
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 dense and front-loaded with purpose, then behavioral caveats, usage guidance, and formatting rules. The date-format sentence is somewhat redundant with the schema but earns its place as a quick-reference. No filler sentences are present.
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 one-parameter tool with no annotations or output schema, the description covers purpose, usage timing, moderation behavior, anonymity, and input completeness guidance. Minor gaps remain: it does not state what a successful submission returns, nor explicitly instruct the agent to verify the event is absent before calling create_event_tip.
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 description coverage is 100% with detailed per-field explanations and formats, so a baseline of 3 is appropriate. The description adds a global 'include as much detail as possible' instruction and a concrete date/time example, slightly reinforcing but not significantly extending what the schema already provides.
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: 'Submit a tip about a flea market event discovered from an external source.' It clarifies the tool's role versus the read/search siblings by saying it is for event information that does not yet appear in the Svapp database. This makes the tool's 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 'Use this when you find event information that does not yet appear in the Svapp database,' which gives clear context for selection. It does not explicitly name alternatives like search_events or get_event, but the read-vs-write contrast with sibling tools is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full markdown body and metadata of a single published article from Svapp by its numeric article ID. Returns the article title, author, published date, short description, and the full markdown Body. ShortDescription is an optional, editor-written summary (max 200 characters) and may be null. Use the ArticleId field from SearchArticles results to get the ID. Only published articles are accessible.
| Name | Required | Description | Default |
|---|---|---|---|
| articleId | Yes | Numeric article ID from a SearchArticles result (the ArticleId field). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states what fields are returned, that the body is full markdown, that ShortDescription may be null, and that unpublished articles are inaccessible. It does not mention authentication or error behavior, but the core behavior is well disclosed.
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 front-loaded: the first sentence states the action and resource, and the following sentences add necessary details without fluff. Every sentence contributes to the agent's ability to use the tool correctly.
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 annotations, the description appropriately explains how to get the ID, what the tool returns, and an important access restriction. It could optionally mention error handling for missing or unpublished articles, but for a one-parameter retrieval tool, the description is substantially complete.
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 describes articleId as 'Numeric article ID from a SearchArticles result (the ArticleId field),' meeting 100% schema description coverage. The tool description mostly repeats this same information, adding a small amount of context about published articles but no genuinely new parameter-level meaning.
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 a specific verb and resource: 'Retrieve the full markdown body and metadata of a single published article from Svapp by its numeric article ID.' It clearly distinguishes the tool from siblings like search_articles and get_event by emphasizing single-article retrieval by ID.
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 tells the agent to obtain the ArticleId from SearchArticles results, which provides actionable usage guidance. It also notes that only published articles are accessible. It does not explicitly name sibling alternatives or say when not to use this tool, but the guidance is clear enough for a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full details of a single published flea market event from Svapp by its numeric event ID. Returns richer data than the search results, including full description, contact information, delivery dates, accepted goods categories, and external links. Use the EventId field from SearchEvents results to get the ID. Only published events are accessible.
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | Numeric event ID from a SearchEvents result (the EventId field). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explains that the tool is a read operation ('Retrieve'), that only published events are accessible, and what richer data is returned (description, contact information, delivery dates, accepted goods categories, external links). It does not cover error handling or authorization, but the disclosed behavior is sufficient for a simple getter.
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?
Three concise sentences each add value: the first defines the action and resource, the second clarifies the response richness, and the third gives ID sourcing guidance. There is no filler or redundant explanation beyond what is necessary.
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 tool with no output schema, the description is complete enough for an agent to call it correctly. It specifies the input source, the access constraint, and the type of data returned, so the agent understands both how to invoke it and what to expect.
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% and the parameter description already explains that eventId is a numeric event ID from a SearchEvents result. The tool description repeats this guidance but does not add substantial new meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and a clearly defined resource ('a single published flea market event from Svapp') with a concrete lookup key ('numeric event ID'). It also distinguishes itself by noting it 'Returns richer data than the search results', which separates it from search_events and get_article.
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 gives clear usage context by instructing to use the EventId field from SearchEvents results and by warning that only published events are accessible. It does not explicitly enumerate exclusions or alternative tools, but the resource distinction and the reference to SearchEvents make the intended workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search published articles (guider and blog posts) on Svapp — Norway's platform for flea markets and second-hand sales. Acts as both a listing and a search tool in one: omit SearchText to list all published articles (returned paged), or provide SearchText to filter articles by title and body content. Returns paged results; use Page and PageSize to paginate. Only publicly published articles are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| dto | Yes | Search criteria. Omit SearchText to get all published articles; provide SearchText to filter by title and body content. Paging via Page and PageSize. |
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 discloses that results are paged and limited to publicly published articles, which is useful, but it does not mention search matching details, sorting, rate limits, or response payload shape. The transparency is reasonable but incomplete.
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 with the purpose front-loaded, followed by mode-specific behavior, pagination, and visibility constraints. The Svapp platform context is slightly extraneous but not harmful, and there is no redundant content.
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 one-parameter nested search tool, the description covers the list/search modes, pagination, and access scope well enough to invoke correctly. Since there is no output schema, the phrase 'Returns paged results' partially addresses return behavior, though a fuller response-shape description would make it more complete.
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 description coverage is 100%, so the schema already documents all parameters. The description mostly restates the schema's searchText and pagination semantics, with the 'omit/provide SearchText' phrasing adding only minor usage clarity. It does not meaningfully supplement 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 explicitly states 'List or search published articles (guider and blog posts)' with a clear verb and resource, and frames the tool as a combined listing and search endpoint. It differentiates from sibling search_events by targeting articles, and from get_article by covering list/search rather than single-article retrieval.
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 provides strong operational guidance: omit SearchText to list all published articles, provide SearchText to filter by title and body, and use Page/PageSize for pagination. However, it does not mention when to prefer the sibling get_article for a single article or state explicit exclusions, leaving tool-selection guidance mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for published flea market events (loppemarkeder) on Svapp — Norway's platform for flea markets and second-hand sales events. Supports free-text search, date range filters, and geographic proximity search (provide NearLatitude, NearLongitude, and RadiusKm to find events near a location). Returns paged results; use Page and PageSize to paginate. Set SortOrder to DistanceAscending (20) when doing a proximity search. Only returns publicly published events.
| Name | Required | Description | Default |
|---|---|---|---|
| dto | Yes | Search criteria. Use NearLatitude + NearLongitude + RadiusKm for proximity search, or SearchText for keyword search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It explicitly states that only publicly published events are returned and that results are paged, which are meaningful behavioral traits. It does not mention auth, rate limits, or return format, but for a search tool the disclosed traits are the most relevant.
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 front-loaded with the core purpose and keeps additional guidance compact. The parenthetical and platform context add a little length, but the overall structure is scannable and directly useful for a complex search API.
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?
The description covers the main search modes, pagination, sorting, proximity-specific behavior, and the published-only constraint. There is no output schema and the exact return shape is not described, but the input side is highly documented and the description is sufficient for selecting and invoking 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?
Schema description coverage is 100%, so the parameter fields already carry detailed meaning. The tool description adds high-level grouping and reiterates the NearLatitude/NearLongitude/RadiusKm combination and DistanceAscending guidance, but it does not add significant new semantic information beyond 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 for published flea market events (loppemarkeder) on Svapp'. It also names the platform and distinguishes the tool from siblings like get_event and search_articles by focusing on event 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?
Clear context is provided for when to use the tool: free-text search, date range filters, and proximity search, with specific instructions to use Page/PageSize and DistanceAscending for proximity. It does not explicitly name alternatives or say when not to use it, but the supported modes are unambiguously described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
create_event_tipget_articleget_eventsearch_articlessearch_eventsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
