Everything involving Legal New York Cannabis. Search dispensaries, brands, licenses, deals and more
Scored across 9 tools
Search/get pairs for brands, dispensaries, and reviews are clearly separated by verb and scope. license_lookup overlaps somewhat with get_dispensary for verifying a license number, but its purpose as a quick legal-check tool is distinct enough from requesting the full dispensary record.
Most tools follow a clear get_/search_ verb-noun pattern with underscores, making the set predictable. license_lookup and market_stats are the only deviations, using noun-style names, but they are still readable and consistent in formatting.
Nine tools is well-scoped for a read-only cannabis directory: search and detail retrieval for the three core entities, plus deals, license verification, and market statistics. Each tool has a clear role without unnecessary bloat.
The surface covers the domain comprehensively: searching and retrieving brands, dispensaries, and reviews, plus deals, market stats, and license verification. Since this is a public read-only directory, lack of create/update/delete tools is not a gap.
Full public record for one brand by slug or name, including which licensed NY dispensaries currently stock it (from crawled menu availability, preview tier), its parent / child brands, and FindWeedNY's own reviews of its products when there are any.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand slug or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say the operation is read-only; the description adds meaningful context: the record is public, stock data comes from crawled menu availability at preview tier, and reviews appear only when they exist. This sets data-source and conditional expectations beyond the readOnlyHint.
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?
A single dense sentence front-loads the core meaning ('Full public record for one brand by slug or name') and every trailing clause adds a specific content facet. There is no filler or repetition of the title.
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 carries the return-value burden and largely satisfies it by enumerating the brand record, dispensary availability, hierarchy, and reviews. It also qualifies availability with source/tier and review inclusion with 'when there are any,' which is enough for a one-parameter read 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 coverage is 100% and already states that the 'brand' parameter is a slug or name. The description mainly repeats that identifier semantics rather than adding examples, casing constraints, or disambiguation guidance, so the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: retrieving the full public record for a single brand. It also enumerates the distinctive contents (NY dispensary stock, parent/child brands, FindWeedNY reviews), which separates it from search_brands and get_review.
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 signals use with a known brand slug or name and says this returns one brand's full record, implying that fuzzy discovery should go through search tools. It does not explicitly name sibling alternatives or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current cannabis deal and promotion PREVIEWS (top deals per dispensary) for one dispensary or a city. The full deal feed requires a free account at findweedny.com.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name (returns up to 5 dispensaries with deals) | |
| limit | No | Max deals per dispensary, default 6 | |
| dispensary_id | No | OCM license number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond the readOnlyHint annotation by disclosing that the tool returns only PREVIEWS/top deals and that the full deal feed requires a free account. This explains the limited scope of the data and hints at an external access requirement, which is helpful behavioral transparency for callers.
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 only two sentences and front-loads the core purpose immediately. Every sentence adds relevant information, and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read-only preview tool, especially with a 100% documented input schema. However, there is no output schema and the description does not clarify what a 'preview' contains or what happens when no city or dispensary_id is provided, leaving some ambiguity for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with city, limit, and dispensary_id each already documented clearly in the input schema. The description adds little beyond restating that deals are organized per dispensary, so it does not meaningfully enhance parameter understanding beyond the structured 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 names a specific resource ('cannabis deal and promotion PREVIEWS'), defines the scope ('top deals per dispensary'), and specifies the two targeting modes ('one dispensary or a city'). This clearly separates it from sibling tools like get_dispensary, get_brand, and get_review, which involve different resources.
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 the tool: when you need previews of deals per dispensary or city, and it implies that the full feed is not available through this tool because it requires a free account. However, it does not explicitly name alternatives or state when-not-to-use conditions, so the usage guidance is mostly inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full public record for one dispensary by OCM license number (e.g. "OCM-CAURD-23-000023"), verified alias, or legacy id. Includes hours, description, and license dates.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | License number, alias, or legacy id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates the safe read-only nature. The description adds useful context by noting the record is public and includes hours, description, and license dates, but it does not disclose much beyond that. No contradiction exists.
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 one compact sentence that front-loads the core purpose, includes the accepted identifier types, and lists key output contents. Every part earns its place and there is no unnecessary wording.
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 one-parameter, read-only tool, the description is mostly complete: it names identifier forms and some return fields. Since there is no output schema, a more complete enumeration of returned fields would be ideal, but 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?
The schema already documents the id parameter with 100% coverage, so the baseline is 3. The description adds value by giving a concrete OCM license number format example ('OCM-CAURD-23-000023') and specifying 'verified alias, or legacy id,' which helps the agent format input correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: get the full public record for one dispensary. It clearly distinguishes itself from search-based siblings by emphasizing 'one dispensary' and by listing the accepted identifier types (OCM license number, verified alias, legacy 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 implies the tool should be used when you already have an identifier for a single dispensary and need its full record. It does not explicitly mention alternatives or state when not to use this tool versus siblings like license_lookup or search_dispensaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One review by slug (from search_reviews) with the full lab panel: every cannabinoid and terpene measured, batch number, price paid, COA link, and the excerpt. Full review text stays on the linked page.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Review slug, e.g. "1slice-superboof-flower" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral detail by listing exactly what the tool returns (cannabinoids, terpenes, batch number, price paid, COA link, excerpt) and what it does not return (full review text stays on the linked page). This is valuable beyond the annotation.
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 filler. The key operation and source are front-loaded, and the important limitation about full review text is stated concisely. Every sentence adds 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?
For a simple one-parameter read-only tool with no output schema, the description provides a complete picture of what is returned and what is intentionally omitted. An agent can select and invoke this tool correctly without needing additional context.
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 the slug parameter with an example. The description adds the useful constraint that the slug comes from search_reviews, but this is a minor addition rather than a substantial clarification.
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 specific operation: get one review by slug, and differentiates it from search_reviews by specifying that a slug is used rather than a search query. It also names the source of the slug, making the tool's role in a workflow 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 phrase 'from search_reviews' gives clear context that this tool is intended to retrieve a specific review after obtaining its slug from the search tool. It does not explicitly list exclusions or alternative tools, but the workflow implication is strong and easy for an agent to act on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a New York OCM cannabis retail license number. Returns whether it matches a licensed dispensary in the directory, with license type, status, and holder. Useful for verifying that a shop is legally licensed in New York State.
| Name | Required | Description | Default |
|---|---|---|---|
| license_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering safety. The description adds useful behavioral detail beyond that: it reports whether the number matches a licensed directory entry and returns license type, status, and holder. This helps set expectations for the lookup's behavior.
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 sentences with no fluff; the primary action and purpose are front-loaded, and the secondary use-case is stated compactly. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only lookup tool, the description covers the operation, expected input, and typical output fields. It is slightly light on edge-case behavior such as invalid or non-matching numbers, but the core context needed to invoke the tool correctly is present.
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 0%, so the description must clarify the parameter. It does specify that the license_number should be a New York OCM cannabis retail license number, which adds domain meaning beyond the bare parameter name. It does not provide format examples or normalizations, which is a minor gap.
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 uses a specific verb ('Check') and a precise resource ('New York OCM cannabis retail license number'), and clearly states the outcome. It distinguishes itself from sibling tools like search_dispensaries or get_brand by focusing on license validation rather than general dispensary or brand data.
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 a clear use case: verifying that a shop is legally licensed in New York State. However, it does not explicitly state when to use this tool instead of alternatives such as search_dispensaries or get_dispensary, nor does it mention any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary statistics for the New York licensed cannabis market: dispensary totals, counts by license type and tier, microbusiness / delivery / non-operational counts, top cities, dispensaries opened and closed in the last 90 days, and brand totals by type and grow method.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds useful context about the exact statistics included, such as counts by license type, opened/closed in the last 90 days, and brand totals, but it does not disclose details like data freshness, aggregation level beyond the implied state scope, or return structure. This is adequate given the annotation, but adds limited extra behavioral 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 a single, well-organized sentence that front-loads the core purpose ('Summary statistics') before enumerating the included metrics. There is no filler or redundant wording; every element specifies a distinct category of returned data.
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 parameterless, read-only aggregate tool with no output schema, the description fully covers what an agent needs to know: it lists the substantive categories of statistics returned. No critical usage context is missing, and the readOnlyHint covers the safety profile.
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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meaning, and it instead clarifies what the no-argument call will return, which is appropriate for this stateless aggregate endpoint.
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 identifies the tool's purpose as returning summary statistics for the New York licensed cannabis market, with a specific list of included metrics. This distinguishes it from siblings like get_dispensary or search_dispensaries, which target individual entities or searches rather than aggregate market data.
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 conveys clear context: use this tool when aggregate market statistics are needed, not when looking up a specific dispensary, brand, review, or deal. It does not explicitly name alternatives or exclusion conditions, but the content makes the appropriate use case obvious relative to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cannabis brands sold in New York. Filter by name, product category (e.g. flower, vapes, edibles, pre-rolls), brand type (local / national / mso), New York origin, microbusiness licensees, grow method (indoor / outdoor / mixed-light / combination — from OCM cultivator licenses; "sun-grown" and "greenhouse" accepted as aliases), ownership certification (woman-owned, veteran-owned, bipoc-owned, social-equity…), tag, or parent brand (the house that owns it — e.g. which brands PharmaCann or 1 Off run in NY). Rows include growType, licenseType, certifications, tags and how many dispensaries stock the brand.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Catalog tag, e.g. "craft", "small-batch", "living-soil", "hudson-valley" | |
| type | No | ||
| limit | No | Max rows, default 10, cap 50 | |
| query | No | Substring match on brand name | |
| offset | No | Rows to skip for paging: the result echoes `total` and `offset`, so request offset + limit for the next page | |
| parent | No | Only brands owned by this parent brand / house (slug or name), e.g. "1-off", "PharmaCann", "GTI" | |
| category | No | Product category, e.g. "vapes" | |
| ny_based | No | ||
| grow_type | No | Cultivation method from OCM license data. sun-grown = outdoor; greenhouse = mixed-light or combination | |
| certification | No | Ownership/impact certification, e.g. "woman-owned", "veteran-owned", "bipoc-owned", "social-equity" | |
| microbusiness | No | Only brands holding a NY microbusiness license |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral detail: it discloses the row fields returned, the grow-method alias behavior ('sun-grown' and 'greenhouse' accepted as aliases), and the parent-brand semantics. This gives the agent a clear picture of tool behavior without contradicting the annotation.
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 the action and resource, and the length is justified by 11 parameters and no output schema. However, it is a long single flow of enumerations, so it could be slightly more scannable without losing information.
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 complexity of 11 optional parameters and no output schema, the description covers the key return fields, filter semantics, alias handling, and category examples. Pagination details such as total and offset are already documented in the input schema, so nothing critical is missing for an agent to invoke 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?
With 82% schema description coverage, the baseline is already solid, but the description enriches several parameters beyond the schema: it clarifies grow_type aliases, explains parent brand as the owning house, and gives concrete examples for category and certification. This adds meaning rather than merely repeating 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 clearly states the verb ('Search'), the resource ('cannabis brands'), and the scope ('sold in New York'). It is easily distinguished from sibling tools like get_brand, search_dispensaries, and search_reviews because it names the resource and filtering surface explicitly.
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 strong context for when to use the tool by specifying all major filter dimensions and the type of rows returned. However, it does not explicitly contrast it with alternatives such as get_brand for a single brand lookup or search_dispensaries for finding stores, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search licensed New York State cannabis dispensaries (adult-use and medical). Free-text query is ranked and typo-tolerant (name, DBA, city, neighborhood, address, ZIP, license) and may include the site search operators (zip: city: county: neighborhood: brand: product: is:open|operating|delivery|micro|medical|verified|closed radius:N — quote multi-word values). Structured filters do the same thing explicitly. NOTE: brand filters against the PUBLIC availability preview (≤10 listed stores per brand); the result's brandAvailability block gives the true known count and, with city/county, how many stores there stock the brand even when none are listed — never conclude "nobody in X carries it" from an empty list. Sort by relevance (default with a query), distance (default when near is given), name, or recently_opened. Returns compact rows; each row has a citable url, Google rating/review count when known, openNow + hoursToday from posted hours (New York time), and a closure object (date, reason, temporary) when a shop has closed.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit ZIP code | |
| city | No | Exact city name, case-insensitive (e.g. "Buffalo") | |
| near | No | Filter/sort by distance from a point | |
| sort | No | ||
| brand | No | Only dispensaries stocking this brand (name or alias) | |
| limit | No | Max rows, default 10, cap 50 | |
| query | No | Ranked, typo-tolerant search over name/DBA/city/neighborhood/address/ZIP/license; accepts operators, e.g. "housing works", "gotham zip:100", "brand:ayrloom is:open" | |
| county | No | Exact county name, case-insensitive | |
| offset | No | Rows to skip for paging: the result echoes `total` and `offset`, so request offset + limit for the next page | |
| medical | No | Only dispensaries serving medical patients | |
| delivery | No | Only dispensaries that offer delivery | |
| open_now | No | Only dispensaries open right now by posted hours | |
| verified | No | Only owner-verified / claimed listings | |
| neighborhood | No | NYC neighborhood name or slug | |
| microbusiness | No | Only microbusiness licensees |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, reducing the burden, yet the description still adds abundant behavioral context: typo-tolerant ranking, operator syntax, sort-default behavior, and output shape (url, rating/reviews, openNow/hoursToday, closure object). This exceeds what the schema and annotations disclose.
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?
In four sentences the description manages scope, query syntax, sorting behavior, and return shape. There is no filler, and the most important information—licensed NY dispensaries and free-text/operator behavior—is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, it already gives the caller a clear picture of result rows, including url, ratings, hours, and closure. With 15 parameters and nested objects, the description is unusually complete and enough for correct invocation and interpretation.
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 93%, so the baseline is 3. The description adds real value by defining the free-text operators (zip:, is:open, radius:N, etc.), explaining the sort/query interaction, and explicitly noting that structured filters reproduce the same semantics. It enriches several parameters without repeated what the schema already says.
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 clear verb-resource statement: 'Search licensed New York State cannabis dispensaries (adult-use and medical).' It distinguishes the tool from siblings like search_brands and search_reviews by specifying the resource (dispensaries) and geographic scope, and it previews the free-text/structured-filter capability.
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: search for NYS dispensaries, with two modes (free-text operators vs structured filters) and sort default behavior described. It doesn't explicitly name alternative tools or state when not to use it, so it's a strong 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FindWeedNY's own independent, lab-anchored reviews of New York cannabis products (flower, vapes, concentrates, edibles). Every review has a 1–5 rating and, for cannabis products, the COA numbers: THC %, total terpenes %, top terpenes, plus a link to the certificate of analysis. Filter by brand, product type, strain, cultivation method, or minimum rating; sort by date, rating, or terpenes. Use this for "is brand X any good", "best-tested flower", or "most terpene-rich vape" questions. Rows carry an excerpt and a url to the full review.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Default date (newest first) | |
| brand | No | Brand name or slug | |
| limit | No | Max rows, default 10, cap 50 | |
| query | No | Text match on title, product, brand, or strain | |
| offset | No | Rows to skip for paging: the result echoes `total` and `offset`, so request offset + limit for the next page | |
| strain | No | Strain or type, e.g. "hybrid", "sativa", "indica", or a strain name | |
| min_rating | No | 1–5 | |
| cultivation | No | ||
| product_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety; the description adds useful behavioral context beyond that: reviews are independent, lab-anchored, include COA numbers for cannabis products, and return excerpts plus a URL to the full review. This gives the agent a realistic expectation of the output without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: it opens with the core resource, then details the data carried, then lists filters and sorts, then gives use examples, then mentions output fields. Every sentence adds actionable information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description adequately covers return shape ('Rows carry an excerpt and a url to the full review'), core data fields, and filtering/sorting capabilities. It is complete enough 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?
Schema coverage is 78% and most parameters have descriptions. The description adds value by explaining the intended semantics of key filters ('brand, product type, strain, cultivation method, or minimum rating') and connecting them to natural-language use cases. It doesn't fully spell out every parameter, but it supplements the schema effectively.
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 identifies the resource (FindWeedNY's own reviews of New York cannabis products), the action (search/filter/sort), and the result format (rows with excerpts and URLs). It also distinguishes itself from the sibling get_review by emphasizing that rows carry only excerpts and a link to the full review.
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 example use cases: 'is brand X any good', 'best-tested flower', and 'most terpene-rich vape'. It does not explicitly mention when not to use it or name alternatives, but the use cases and focus on summary-level reviews imply the boundary well.
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.
get_brandget_dealsget_dispensaryget_reviewlicense_lookupmarket_statssearch_brandssearch_dispensariessearch_reviewsClaiming 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!
