toco-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
All tools use snake_case with a verb_noun pattern: get_* for detail retrieval, search_* for querying. Consistent and predictable naming convention throughout.
Tool Count5/5
12 tools is well within the ideal 3-15 range; each tool covers a distinct read-only operation with no redundancy or bloat.
Completeness5/5
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.
Average 4/5 across 12 of 12 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on September 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
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. 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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
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. 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/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 ('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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines4/5
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.
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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. 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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
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 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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

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

toco-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![toco-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/bintangtimurlangit/toco-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bintangtimurlangit/toco-mcp)

Score Badge

Copy to your README.md:

[![toco-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/bintangtimurlangit/toco-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bintangtimurlangit/toco-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/bintangtimurlangit/toco-mcp'

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