Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@toco-mcp Find second-hand Avanza under Rp150 million"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A zero-config Model Context Protocol server for discovering Toco — Indonesia's community marketplace, founded by the creator of Tokobagus and built on 0% sales commission.
No login, no API key, no browser automation. Toco serves its catalogue over a public JSON API, so this server is a plain HTTP client. It is strictly read-only: it searches and reads, and never carts, buys, messages, or writes anything.
🔍 Search products — free-text plus price, condition, city, category, and official-store filters
💡 Autocomplete — see how sellers actually spell a product before searching
📦 Product detail — description, effective price, stock, shipping dimensions, category path, seller
🎨 Variants — per-SKU price and stock across variant axes like Color and Size
🎟 Promos — vouchers and free-shipping subsidies a listing qualifies for
📝 Reviews — ratings and written reviews with the overall summary
🏬 Stores — seller profiles, their catalogue, and store search
🗂 Categories — the full department → category → type taxonomy
🚗 Vehicle ads — classified cars and motorbikes, filtered by year, mileage, transmission
🏠 Property ads — houses and land for sale or rent, filtered by bedrooms and area
Related MCP server: storebridge-mcp
npm install -g @bintangtimurlangit/toco-mcpAdd to your MCP client config (for Claude Desktop, claude_desktop_config.json):
{
"mcpServers": {
"toco": {
"command": "npx",
"args": ["-y", "@bintangtimurlangit/toco-mcp"]
}
}
}That's the whole setup — there is nothing to authenticate. See docs/CONFIGURATION.md for local-build and tuning options.
Tool | Description |
| Search buyable marketplace products with filters and sorting |
| Autocomplete suggestions for a partial search term |
| Full detail for one listing |
| Every variant SKU with its own price and stock |
| Vouchers and promotions a listing is eligible for |
| Reviews and rating summary |
| A seller's profile |
| What a specific store sells |
| Find sellers by name, city, or official status |
| Browse the taxonomy and get category UUIDs |
| Classified car and motorbike ads |
| Classified property ads |
Product and store arguments accept either a slug (sepatu-pria-30) or a pasted URL
(https://toco.id/listing/sepatu-pria-30).
Toco is two catalogues behind one search index, split by an add_to_cart flag:
Marketplace listings are buyable — they have stock, variants, and a cart. Use search_products.
Classified listings are contact-the-seller ads — vehicles, property, services. Use search_vehicles / search_properties.
Searching for "avanza" with the wrong one returns car parts instead of cars, so the
tools are split along that line rather than exposing the flag as a filter.
Find running shoes on Toco under Rp300.000, sorted by most sold.
What variants does this Toco listing have, and which sizes are out of stock?
Show me second-hand Toyota Avanzas from 2018 or newer with under 100,000 km.
Find 3-bedroom houses for sale in Bandung with at least 100 m² of building area.
Which official Toco Mall stores sell coffee, and what are they rated?
Toco API reference — the reconnaissance notes this server is built on
Unofficial and not affiliated with, endorsed by, or sponsored by Toco. It reads the same
public endpoints a visitor's browser does, at a browser's pace. Respect Toco's
terms of service. Because it depends on undocumented endpoints,
Toco can change them at any time — npm test is the tripwire that catches it.
MIT © bintangtimurlangit
Browse Toco's category taxonomy and get the UUIDs that search_products, search_vehicles, and search_properties accept as departmentId / categoryIds. Start with depth 1 for the department list, then drill into one department by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | How deep to render: 1 = departments, 2 = + categories, 3 = + types (default: 1). The full tree is large, so widen this only after narrowing by department. | |
| department | No | Department slug to drill into, e.g. "fashion-pria". Omit for all departments. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It clearly indicates a read-only browsing/getting behavior and describes the depth/department navigation model. It does not mention response format or error behavior, but the core behavior is transparent.
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 concise and well structured, with two sentences that convey purpose, consumers, and navigation workflow without extraneous detail.
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 gives enough context for an agent to select and start using the tool: it names downstream consumers, explains depth/department parameters, and suggests a starting workflow. It could include response shape hints, but this is not critical for initial selection.
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 fully describes both parameters, so baseline is 3. The description adds workflow semantics by instructing to start at depth 1 and drill into a department by slug, clarifying how the parameters relate to navigation.
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?
Clearly identifies the tool's purpose: browsing Toco's category taxonomy to obtain UUIDs used by three search tools. The verb 'Browse' and resource 'category taxonomy' are specific, and it differentiates from sibling search tools by being the source of their ID parameters.
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?
Provides practical usage context by specifying a workflow: start at depth 1 for departments, then drill into a department by slug. It connects the output to downstream search tools, though it does not explicitly contrast with alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full detail for one Toco listing: description, effective price, stock, condition, shipping weight and dimensions, category path, seller info, and whether it has variants. Works for both marketplace products and classified ads.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug (the `slug` field from search_products) or a full toco.id/listing/... URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not mention any side effects, permissions, or error handling. As a 'get' operation, it is implicitly read-only, but the description does not explicitly state this or any rate limits or other behaviors.
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 a single, information-dense sentence that covers scope, content, and applicability without unnecessary elaboration.
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?
It enumerates the key fields returned (description, price, stock, condition, shipping, category, seller, variants) and notes that it covers both product types, giving the agent a solid expectation of the output.
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 product parameter description explains that it accepts either a slug from search results or a full URL, providing precise guidance on the expected input format.
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 clearly states the tool's function: retrieving full details for a single Toco listing, and enumerates specific fields included. It distinguishes from sibling search tools by emphasizing 'one listing' and 'full detail'.
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 the tool works for both marketplace products and classified ads, giving a clear context for when to use it. It also implies it is for single items, not batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the vouchers and promotions a Toco listing is currently eligible for — free-shipping subsidies, discounts, minimum spend, and expiry dates.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug (the `slug` field from search_products) or a full toco.id/listing/... URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation and lists the kind of promotional data returned, but it does not disclose side effects, error behavior, authentication requirements, or output structure. Since no annotations are provided, some behavioral details are missing.
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 a single, clear sentence with no redundant or vague phrasing. It efficiently communicates the tool's purpose and the main data points covered.
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 tool with one input parameter and no output schema, the description provides sufficient context about what the tool returns (vouchers, promotions, discounts, expiry dates). It does not describe the exact response format, but that is not critical for this simple use case.
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 parameter 'product' is fully described in the schema, including its type, requirement, and acceptable forms (slug or URL). The tool description adds no extra parameter meaning, so the baseline score applies.
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 clearly states the tool's action ('List') and resource ('vouchers and promotions a Toco listing is currently eligible for'), and it is distinct from sibling tools like get_product_detail or get_product_variants by focusing specifically on promotional offers.
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 intended use is implied by the description, but it does not explicitly explain when to choose this tool over alternatives such as get_product_detail or search_products. There is no direct comparison or condition stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get customer reviews and the rating summary for a Toco listing. Toco server-renders reviews rather than exposing a review API, so this returns the set shown on the product page (most recent first) alongside the overall average and total count.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug (the `slug` field from search_products) or a full toco.id/listing/... URL | |
| minRating | No | Only show reviews at or above this star rating | |
| withTextOnly | No | Skip star-only ratings that carry no written review (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the output (most recent reviews, average, total count) and that it mirrors the product page data. It does not state side effects, but as a get operation, it is reasonably transparent.
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?
Two concise sentences provide all necessary information without redundancy. The purpose and output are clearly stated.
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 gives a good overview of what is returned, but does not mention error handling, pagination, or edge cases. However, for a simple review retrieval tool, this level of detail is sufficient.
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 baseline is 3. The description does not add much to parameter meanings beyond the schema, but the schema itself is clear (product slug/URL, minRating, withTextOnly).
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 clearly states the tool retrieves customer reviews and rating summary for a Toco listing, distinguishing it from sibling tools like get_product_detail or get_product_variants by focusing specifically on reviews.
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 explains why this tool exists (Toco server-renders reviews rather than exposing an API) and what it returns, giving clear context for when to use it. It does not explicitly name alternatives but implies the scope is reviews.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every variant SKU of a Toco product with its own price, stock, and SKU code. Returns the variant axes (e.g. Color, Size) and flags which combinations are out of stock.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product slug (the `slug` field from search_products) or a full toco.id/listing/... URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It implies a read-only operation (no side effects mentioned), but does not explicitly state that it is safe or idempotent.
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 two sentences, directly to the point, with no filler or redundant wording. It efficiently conveys the core functionality and return value.
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 key return aspects (variant axes, out-of-stock flags). It lacks details on error handling or pagination, but given the simple single-parameter tool, it is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'product' is fully described in the schema with a clear explanation. The description adds no additional meaning beyond the schema, so baseline 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 clearly states the tool lists every variant SKU with price, stock, and SKU code, and specifies the resource (Toco product). This distinguishes it from sibling tools like get_product_detail or get_product_promos.
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?
No explicit instruction on when to use this tool versus alternatives. The description implies it is for variant-level data, but it does not explicitly contrast with sibling tools like get_product_detail or search_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Toco's autocomplete suggestions for a partial search term. Useful for discovering how sellers actually spell a product before running search_products.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max suggestions (default: 10) | |
| query | Yes | Partial search term, e.g. "sepa" | |
| officialOnly | No | Bias suggestions to official Toco Mall stores (default: false) |
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. However, it only states that it returns suggestions without detailing the response format, any filtering behavior, rate limits, or whether the operation is read-only (though the 'Get' verb implies it). This lack of disclosure leaves the agent uncertain about what to expect.
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 two sentences with no wasted words. The core action and purpose are front-loaded, and it efficiently points to the primary use case 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?
For a simple tool with three well-documented parameters and no output schema, the description is adequate but not complete. It omits details about the return shape (e.g., list of strings vs. objects) and any edge cases, which an agent would benefit from knowing. Since complexity is low, this is a moderate gap, not severe.
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 each parameter having a meaningful description (e.g., query example, limit bounds, officialOnly meaning). The tool description adds no extra parameter context, but the schema already provides sufficient semantics, so the baseline of 3 applies.
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 clearly states the action ('Get'), the resource ('Toco's autocomplete suggestions'), and the specific purpose ('discovering how sellers actually spell a product'). It also distinguishes itself from the sibling search_products by positioning it as a pre-search step, making its role 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?
The description explicitly indicates when to use the tool ('before running search_products') and why it's useful (spelling discovery). It does not enumerate alternatives or exclusions, but the context is clear enough for an agent to decide when this is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Toco seller's profile: display name, city, description, rating, active product count, official/tier badges, and KYC status. Takes the store short name (e.g. "ysn-store") or a full toco.id/store/... URL.
| Name | Required | Description | Default |
|---|---|---|---|
| store | Yes | Store short name or full toco.id/store/... URL |
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 clearly signals a read-only lookup through 'Get', but it does not explicitly state that it has no side effects, does not require unusual permissions, or discuss error/availability edge cases. This is adequate for a simple retrieval tool but not fully transparent.
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 brief and front-loaded, leading with the action and the most critical payload (seller's profile), then listing output fields and input forms. It wastes no words. It could be slimmed by dropping the input-format sentence since the schema already says that, but the example is a helpful convenience.
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 tool is low in complexity: one required param, no enums, no output schema. The description compensates for the absence of an output schema by listing what the agent will get. It doesn't mention errors or authentication, but for a straightforward by-key profile fetch, this is close to being complete enough.
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 cover is 100% and the schema description already says exactly what the description says: a short name or URL. The description adds only a small clarifying example like 'e.g. "ysn-store"' which is useful but not fundamental. Baseline of 3 applies because the schema already carries full parameter documentation.
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?
Description states a specific verb and resource ('Get a Toco seller's profile') and enumerates concrete fields returned (display name, city, rating, active product count, official/tier badges, KYC status). This clearly differentiates it from siblings like get_store_products (products, not profile) and search_stores (search, not profile-by-identifier).
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's niche by noting it takes a short name or full URL, which tells the agent this is the 'by-identifier' lookup rather than search_stores. However, it doesn't explicitly say when to use this over get_store_products or when a search tool would be more appropriate, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the products a specific Toco store sells, with optional keyword and price filtering. Takes the store short name or a full toco.id/store/... URL.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| sort | No | Sort order (default: relevance) | relevance |
| limit | No | Results per page (default: 20) | |
| query | No | Optional keywords to search within the store | |
| store | Yes | Store short name or full toco.id/store/... URL | |
| maxPrice | No | Maximum price in IDR | |
| minPrice | No | Minimum price in IDR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It mentions filtering and input format but does not state whether the operation is read-only, describe pagination behavior, or explain output/error expectations.
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 a single, focused sentence that front-loads the primary purpose and then mentions key filtering options and input format. No superfluous 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?
Given the simple list operation and full schema coverage, the description plus schema provides enough for an agent to make a correct call. It lacks explicit guidance on output shape or error handling, but these are not critical for such a 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?
Schema descriptions cover all 7 parameters (100% coverage), so the baseline applies. The description adds minimal extra meaning beyond the schema, such as noting 'optional' filtering, but does not clarify edge cases like price inclusivity.
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 clearly states the tool lists products for a specific store, with keyword and price filtering, and specifies the store input format. It is distinct from global search tools but does not explicitly name alternatives.
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 usage for a specific store's catalog but does not explicitly direct users to sibling tools like search_products for global searches or search_stores for store discovery. Guidance is largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search buyable products on the Toco marketplace (toco.id). Supports free-text queries plus price, condition, city, category, and official-store filters. Returns titles, prices, ratings, sales counts, stores, and product URLs. For cars, motorbikes, or property use search_vehicles / search_properties instead — those are classified ads, not buyable products.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| sort | No | Sort order (default: relevance) | relevance |
| limit | No | Results per page, max 50 (default: 20) | |
| query | No | Search keywords, e.g. "sepatu pria". Omit to browse by filters alone. | |
| cities | No | Filter by city names as Toco spells them, e.g. ["Kota Bandung"] | |
| maxPrice | No | Maximum price in IDR | |
| minPrice | No | Minimum price in IDR | |
| condition | No | Filter by item condition. Omit to include both. | |
| categoryIds | No | Category UUIDs from get_category_tree | |
| departmentId | No | Department UUID from get_category_tree | |
| officialOnly | No | Only return listings from official Toco Mall stores (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does mention that it returns specific fields (titles, prices, ratings, sales counts, stores, product URLs), which is good. But it does not explicitly state that the operation is read-only or non-mutating, nor does it describe potential side effects or error behavior. For a search tool, read-only is implied but not stated.
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 two sentences with no redundancy. Every clause adds value: the primary purpose, supported filters, return fields, and alternative tool guidance. It is well structured and easy to parse.
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 complexity (11 optional parameters, no output schema), the description conveys everything an agent needs to invoke it correctly: what it does, what it returns, and when to choose a different tool. References to get_category_tree and the alternative search tools complete the contextual picture.
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 provides full descriptions for all 11 parameters, and the description adds extra clarification: city names must match Toco's spelling (e.g., 'Kota Bandung'), category and department IDs come from get_category_tree, and omitting query allows browsing by filters. This goes beyond the schema and enriches parameter understanding.
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 clearly states the tool searches for buyable products on the Toco marketplace and differentiates it from adjacent tools like search_vehicles and search_properties by specifying they handle classified ads. The verb 'search' and resource 'products' are explicit.
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 explicit guidance for when to use this tool versus alternatives: 'For cars, motorbikes, or property use search_vehicles / search_properties instead'. It also hints at using get_category_tree for category and department IDs, and clarifies that fields like condition and query can be omitted. However, it does not explicitly contrast with get_search_suggestions, though the difference is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search classified property ads on Toco — houses, apartments, and land for sale or rent. Filter by bedrooms, bathrooms, building and lot area, and sale-vs-rent. These are contact-the-seller ads, not add-to-cart products.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| sort | No | Sort order (default: relevance) | relevance |
| limit | No | Results per page (default: 20) | |
| query | No | Keywords, e.g. "rumah bandung". Omit to browse by filters alone. | |
| cities | No | Filter by city, e.g. ["Kota Medan"] | |
| maxPrice | No | Maximum price in IDR | |
| minPrice | No | Minimum price in IDR | |
| minLotArea | No | Minimum lot area in m² | |
| listingType | No | Restrict to properties for sale or for rent. Omit for both. | |
| minBedrooms | No | Minimum number of bedrooms | |
| minBathrooms | No | Minimum number of bathrooms | |
| minBuildingArea | No | Minimum building area in m² |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states that the ads are contact-the-seller, implying no direct online purchase, which is useful behavioral context. However, it does not mention other behaviors like pagination, result format, or any side effects, leaving room for ambiguity.
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 two concise sentences, front-loaded with the core action and scope, and efficiently communicates key distinctions and filter categories without unnecessary detail.
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 complexity (12 parameters, no output schema), the description provides essential context: what is searched, the domain, and the interaction model (contact-seller). It does not detail pagination or result structure, but that is not strictly required without an output schema. The description is adequate for an agent to select and invoke 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 schema already provides 100% description coverage for all 12 parameters, so the baseline is 3. The description text adds a high-level summary of filter types (bedrooms, bathrooms, area, sale/rent) but does not add new meaning beyond the schema. It reinforces but does not enhance parameter understanding.
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 clearly states the tool searches classified property ads, specifies property types (houses, apartments, land) and transaction types (sale/rent). It also distinguishes this from product search by noting it is not add-to-cart, which is effective given sibling tools like search_products and search_vehicles.
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 when to use it (when searching for property listings) and hints at differentiating it from product search via the 'not add-to-cart' note. It does not explicitly name alternatives, but the context of sibling tools and the property-specific language provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for sellers on Toco by name or description. Filter by city, official-store status, or store tier. Returns store names, cities, ratings, and their toco.id links.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| limit | No | Results per page (default: 20) | |
| query | Yes | Store name or keywords, e.g. "kopi" | |
| cities | No | Filter by city as Toco spells it, e.g. ["Kota Surabaya"] | |
| officialOnly | No | Only official Toco Mall stores (default: false) |
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 discloses the return fields (store names, cities, ratings, toco.id links), which is useful, but it does not mention pagination behavior, rate limits, authentication requirements, or any side effects. For a search operation this is likely read-only, but that is not stated. The description adds some behavioral context but lacks depth.
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 concise, two sentences with the purpose front-loaded. It efficiently states what the tool does and what it returns. However, the inclusion of the nonexistent 'store tier' filter detracts from precision, so it is not a perfect 5.
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 there is no output schema, the description covers the return fields adequately. It does not mention pagination (though schema has page/limit) or any ordering constraints. The misleading 'store tier' filter also reduces completeness. For a simple search tool it is mostly sufficient, but the inaccuracy and missing behavioral notes prevent a higher score.
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 3. However, the description mentions a 'store tier' filter that does not exist in the schema (only cities and officialOnly are available). This is misleading and could cause an agent to look for a parameter that is not present. The description otherwise adds little beyond the schema, and the inaccuracy lowers the score.
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 clearly states the verb 'Search' and the resource 'sellers on Toco', and specifies the search basis (name or description). It also lists filters (city, official-store status, store tier) and return fields (store names, cities, ratings, toco.id links). This distinguishes it from sibling tools like search_products (which searches products) and get_store_info (which retrieves a specific store's details).
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 makes it obvious this tool is for finding stores/sellers, contrasting with product search and store-specific tools. However, it does not explicitly name alternatives or state when not to use this tool. The context is clear enough that an agent would correctly select it for store discovery, but there is no explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search classified vehicle ads on Toco — cars and motorbikes listed by owners and dealers. Filter by production year, mileage, and transmission. These are contact-the-seller ads, not add-to-cart products.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| sort | No | Sort order (default: relevance) | relevance |
| limit | No | Results per page (default: 20) | |
| query | No | Keywords, e.g. "avanza" or "honda beat". Omit to browse by filters alone. | |
| cities | No | Filter by city, e.g. ["Kota Bandung"] | |
| maxYear | No | Latest production year | |
| minYear | No | Earliest production year | |
| maxPrice | No | Maximum price in IDR | |
| minPrice | No | Minimum price in IDR | |
| condition | No | Item condition | |
| maxMileage | No | Maximum odometer reading in km | |
| transmission | No | Filter by transmission type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only search operation but doesn't explicitly state side effects, authorization needs, or data behavior beyond the ad nature. The 'search' verb and classified-ads wording provide implicit transparency, but explicit statements would be stronger.
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 a single, information-dense sentence that conveys the tool's purpose, subject, key filters, and the critical distinction from product listings. No unnecessary words or repetition, and it's well-structured.
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, the description needn't detail return values. It covers what the tool does, the type of content, and the important non-product nature. It doesn't discuss pagination or result format, but that's not required given the schema already has limit/page parameters. The main context is 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?
All parameters are described in the schema (100% coverage), so the baseline is 3. The description adds domain context (vehicles, classified ads) and highlights specific relevant filters, but it doesn't elaborate on each parameter beyond the schema descriptions, which are brief but adequate.
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 clearly states the tool searches classified vehicle ads for cars and motorbikes on Toco, with an explicit note that these are contact-the-seller ads, not add-to-cart products. This both states the primary purpose and distinguishes it from other search tools like search_products.
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 mentions the supported filters (production year, mileage, transmission) and clarifies the ad type, making it obvious when to use this tool instead of search_products or search_properties. It doesn't reference sibling tools by name but the domain and constraints are sufficient.
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.
v1.0.0get_category_treeget_product_detailget_product_promosget_product_reviewsget_product_variantsget_search_suggestionsget_store_infoget_store_productssearch_productssearch_propertiessearch_storessearch_vehiclesEach tool targets a distinct resource or action: search variants for global vs store-specific search, product detail vs variants vs promos vs reviews, and separate tools for vehicles and properties. Clear boundary between search_products (buyable) and classified ads.
All tools use snake_case with a verb_noun pattern: get_* for detail retrieval, search_* for querying. Consistent and predictable naming convention throughout.
12 tools is well within the ideal 3-15 range; each tool covers a distinct read-only operation with no redundancy or bloat.
Covers the full read surface of a marketplace: search, suggestions, category taxonomy, product details, variants, promos, reviews, store info and products, plus specialized search for vehicles and properties. No obvious gaps for a read-only data access layer.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search multi-merchant supply, checkout, and track orders via MCP.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
TomTom MCP — wraps the TomTom Search & Routing APIs (api.tomtom.com)
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bintangtimurlangit/toco-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server