Everything involving Legal New York Cannabis. Search dispensaries, brands, licenses, deals and more
Scored across 9 tools
Each tool has a clearly distinct purpose: get_* tools retrieve a single known entity while search_* tools query across lists, and verify_license handles OCM license lookups separately. Even the get/search pairs are unambiguous because their inputs and outputs are clearly different.
All tool names follow a consistent lowercase snake_case verb_noun pattern: get_brand, search_dispensaries, verify_license, etc. There are no mixed conventions, vague verbs, or stylistic inconsistencies.
Nine tools is well within the ideal range for a domain-specific read-only data server. Each tool covers a meaningful part of the NY cannabis discovery surface without redundancy or bloat.
The server provides search and retrieval for brands, dispensaries, and reviews, plus deals, market stats, and license verification. This covers the core information needs for the stated domain, with no obvious dead ends or missing lifecycle operations for a read-only public data API.
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 |
| Name | Required | Description |
|---|---|---|
| brand | No | |
| found | Yes | |
| source | No | Attribution line — CC BY 4.0, cite the row url |
| message | No | |
| dataUpdated | No | ISO timestamp of the underlying directory export |
| availability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it is safe. The description adds that data comes from crawled menu availability and is preview tier, which is genuinely useful transparency about data provenance. It doesn't disclose pagination or staleness behavior, but those are minor for a single-record lookup.
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, information-dense sentence that front-loads the primary purpose and then adds supporting detail. It earns its length, though it could be split into two sentences for readability.
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 with a 100%-covered schema, the description is largely complete. It names what's included in the result (provenance note, brand hierarchy, reviews) and doesn't need to restate return values since an output schema exists. Minor gaps: no mention of null-result behavior when no dispensaries stock the brand or no reviews exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter description ('Brand slug or name') is sufficient. The tool description confirms the param's meaning by saying lookup is 'by slug or name', but adds no syntax or format details beyond schema. Baseline 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?
States a specific verb ('get'), resource ('brand'), and scope ('full public record'), and lists concrete contents (dispensaries that stock it, parent/child brands, FindWeedNY reviews). The detail level distinguishes it from siblings like search_brands or get_review without needing to open schemas.
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 a lookup-by-identifier use case via slug or name and implies this is the detailed-record counterpart to search_brands. It doesn't explicitly state when to prefer get_review or get_dispensary, so it loses a point on explicit alternatives.
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, cap 10 | |
| dispensary_id | No | OCM license number |
| Name | Required | Description |
|---|---|---|
| note | No | |
| found | No | |
| source | No | Attribution line — CC BY 4.0, cite the row url |
| message | No | |
| results | No | |
| dataUpdated | No | ISO timestamp of the underlying directory export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only. The description adds meaningful behavioral context: only top previews are returned, and the full feed requires a free account at findweedny.com. This goes beyond the annotation without contradicting it.
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 fluff. The core purpose is front-loaded, and the access limitation is stated efficiently in the second sentence.
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 output schema, full parameter documentation, and read-only annotations, the description covers most needed context. It adds the previews-only limitation and account requirement. The only minor gap is not explicitly stating that city and dispensary_id are alternative selectors, but this is largely inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces that city or dispensary_id are the access paths but does not add semantic details beyond the schema, such as exclusivity or required combination. 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 returns current cannabis deal and promotion previews, scoped to one dispensary or a city. It distinguishes itself from the full deal feed and sibling tools, leaving no ambiguity about what resource is being accessed.
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 context for when to use the tool: when current previews for a dispensary or city are needed. It does not explicitly contrast with sibling tools, but none of the siblings offer deal previews, so no exclusion is strictly required. The account note hints at a limitation without specifying exact alternative routing.
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 |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| source | No | Attribution line — CC BY 4.0, cite the row url |
| message | No | |
| dispensary | No | |
| dataUpdated | No | ISO timestamp of the underlying directory export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by calling the record 'public'. It also discloses what the record includes (hours, description, license dates), adding useful behavioral context 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?
Two sentences with no redundancy. The core behavior and accepted identifier types are front-loaded, and the example is compact and informative.
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 with an output schema present, the description covers the identifier variants and the essential record contents. No critical information needed to call the tool correctly is missing.
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 schema already documents the id parameter. The description adds value by giving a concrete OCM license number format and example, which helps the agent construct a valid identifier.
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?
States a specific verb and resource: retrieves the full public record for one dispensary. It clearly distinguishes from search_dispensaries by emphasizing singular lookup by identifier rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is for retrieving a single dispensary when the caller already has a license number, verified alias, or legacy id. It does not explicitly say when to use search_dispensaries instead, but the singular 'for one dispensary' plus identifier-based lookup implies the appropriate context.
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 | |||
| Name | Required | Description |
|---|---|---|
| total | Yes | Licensed dispensaries in the directory |
| brands | No | |
| byTier | No | open | coming-soon | delivery-only → count |
| source | No | Attribution line — CC BY 4.0, cite the row url |
| topCities | No | |
| dataUpdated | No | ISO timestamp of the underlying directory export |
| openDataHub | No | |
| deliveryOnly | No | |
| byLicenseType | No | license type → count |
| medicalServing | No | |
| nonOperational | No | |
| recentlyClosed | No | Closed in the last 90 days |
| recentlyOpened | No | Opened in the last 90 days |
| microbusinesses | No | |
| offeringDelivery | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: it specifies the kinds of counts, time-bounded 90-day metrics, and category breakdowns the tool returns, making the behavior more predictable.
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-structured sentence with a leading summary phrase followed by a colon-delimited list of specific statistics. Every listed item adds value, and there is no filler or redundant repetition of the tool name.
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 that the tool has no parameters, annotations mark it read-only, and an output schema is present, the description is sufficiently complete. It tells an agent exactly what aggregate categories to expect, so no critical invocation details are missing.
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 description does not need to explain parameter meanings. Per the baseline for parameterless tools, this is appropriately handled; the schema is empty and the description focuses on the returned statistics instead.
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 a specific resource: summary statistics for the New York licensed cannabis market. It enumerates the exact aggregates returned, such as dispensary totals, license counts, top cities, and 90-day open/close counts, which differentiates it from the sibling entity-level get/search tools.
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 establishes clear context for use: it is the market-level statistics tool, distinct from get_brand, get_dispensary, get_review, and the search variants. It does not explicitly name alternatives or exclusions, but the scope is unambiguous and no prerequisites are needed.
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" |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| review | No | |
| source | No | Attribution line — CC BY 4.0, cite the row url |
| message | No | |
| dataUpdated | No | ISO timestamp of the underlying directory export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: the tool returns the full lab panel, batch number, price paid, COA link, and excerpt, while deliberately omitting the full review text. This sets accurate expectations about response content.
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. It front-loads the core purpose, lists the return contents efficiently, and ends with a useful boundary about full review text.
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 single-parameter read-only tool with a provided output schema, the description is complete. It explains the input source, the returned fields, and an important limitation, leaving no major ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the slug parameter with an example. The description adds value by explaining that the slug originates from search_reviews, which clarifies how to obtain a valid value.
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 action and resource: retrieving a single review by slug. It also distinguishes itself from siblings like search_reviews by clarifying that the slug comes from search_reviews and by enumerating the unique full lab panel content returned.
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 clearly implies the correct workflow: first call search_reviews to obtain a slug, then call get_review with that slug. It does not explicitly list exclusions or alternative tools for other use cases, but the slug-source guidance is strong and unambiguous.
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 | Brand type: local (NY), national, or multi-state operator | |
| 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 | Only brands headquartered / grown in New York | |
| 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 |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| brands | Yes | |
| offset | Yes | |
| source | No | Attribution line — CC BY 4.0, cite the row url |
| dataUpdated | No | ISO timestamp of the underlying directory export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds valuable behavioral context beyond annotations by specifying the row fields returned (growType, licenseType, certifications, tags, dispensary count) and explaining grow-type aliases such as 'sun-grown' and 'greenhouse'. This helps the agent set expectations for output without contradicting the read-only 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 a single dense sentence that front-loads the core action and then enumerates filters efficiently. It is not overly verbose given 11 parameters, though a bulleted structure could improve scanability. Every clause contributes useful information or examples.
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 11-parameter search tool with an output schema, the description covers all filter dimensions, provides domain-specific nuance (grow method aliases, parent brand concept), and describes the shape of returned rows. Pagination and limits are already covered by the input schema, so nothing critical is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by giving concrete examples for category, certification, and parent brand (e.g., 'PharmaCann or 1 Off'), and by clarifying that grow_type aliases map to OCM cultivator license data. These examples and mappings help an agent choose parameter values more accurately.
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-resource pairing ('Search cannabis brands sold in New York') and immediately enumerates the filter dimensions, making the tool's purpose unmistakable. The reference to 'Rows include...' and the search semantics distinguishes it from the singular get_brand sibling, and the resource 'brands' differentiates it from search_dispensaries and search_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 provides clear context on when to use the tool: any search for cannabis brands with optional filters across many attributes. It does not explicitly name alternatives like get_brand for single-brand lookups, so it stops short of a 5, but the usage context is strong and no exclusions are needed given the sibling set.
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 (results gain a `distance` in miles) | |
| sort | No | Default: relevance with a query, distance with near, otherwise name | |
| 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 |
| Name | Required | Description |
|---|---|---|
| notes | No | Caveats about the filters applied |
| total | Yes | Matches before paging |
| offset | Yes | |
| source | No | Attribution line — CC BY 4.0, cite the row url |
| dataUpdated | No | ISO timestamp of the underlying directory export |
| dispensaries | Yes | |
| brandAvailability | No | Present when a brand filter was applied. Never conclude "nobody carries it" from an empty list — read knownDispensaries / inCity. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=true in annotations, the description carries the full burden and delivers substantially: typo-tolerant ranked search, the brand filter's ≤10-store public-preview limitation with the true count moved to brandAvailability, sort default behavior, and output traits (citable url, Google rating, New York-time hours, closure object). This context far exceeds what the annotation provides and is consistent with the read-only nature of the tool.
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 definition is long but each block earns its place: scope, operator syntax, the critical brand caveat, sort defaults, and output semantics. The final sentence describing return rows overlaps somewhat with the existing output schema, a minor redundancy. Front-loading is strong — purpose appears first and the riskiest nuance (brandAvailability) is positioned where it matters.
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 15-parameter tool with a nested near object, the description covers all high-risk behaviors: operator syntax, the brand false-negative gotcha, sort defaults, and timezone semantics for hours. Pagination is already fully handled in the schema's offset description, and the existing output schema relieves the description of explaining return structure, which it only notes where context matters (citable url, timezone).
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% (baseline 3), yet the description adds genuine value beyond the schema: it enumerates the full query operator syntax (zip:, city:, county:, neighborhood:, brand:, product:, is:open|operating|delivery|micro|medical|verified|closed, radius:N) that the schema only samples with examples, and it flags the brand filter's misleading-empty-list gotcha. It avoids redundantly re-describing simple parameters like zip or city.
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 opening sentence, "Search licensed New York State cannabis dispensaries (adult-use and medical)," states a specific verb, an exact resource, and geographic/regulatory scope. This clearly distinguishes it from siblings like get_dispensary (singular fetch by ID) and search_brands (brands instead of stores). The title reinforces the same purpose with no ambiguity.
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 operational context: sort defaults vary by input, structured filters mirror the free-text operators, and it warns the agent never to conclude a brand is absent from an empty list without checking brandAvailability. However, it never explicitly names alternatives or states when-not-to-use this tool versus get_dispensary or search_brands, so exclusions are left to inference.
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 | How the flower was grown, when the review records it | |
| product_type | No | Kind of product reviewed |
| Name | Required | Description |
|---|---|---|
| note | No | |
| total | Yes | |
| offset | Yes | |
| source | No | Attribution line — CC BY 4.0, cite the row url |
| reviews | Yes | |
| dataUpdated | No | ISO timestamp of the underlying directory export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=true; the description adds useful behavior beyond that: reviews are independent/lab-anchored, ratings are 1–5, cannabis reviews include COA numbers, and rows carry an excerpt and URL. There is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core identity (independent lab-anchored reviews) and every sentence earns its place: content, filters/sorts, use cases, and row shape. It is compact for a 9-parameter search tool.
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 9 optional parameters, 100% schema coverage, an output schema, and a readOnlyHint annotation, the description is complete enough: it explains what is searched, what data is returned, and which queries it is meant for. Any remaining details (pagination, THC sort) are already in the schema.
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 schema already documents all parameters. The description summarizes filters and sorts but doesn't add meaning beyond the schema; it even omits sort=thc and the query/limit/offset parameters, all of which are covered by the schema. 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 names a specific verb and resource—searching FindWeedNY's editorial cannabis reviews—and states the product categories, rating scale, and COA data, so an agent can separate it from search_brands/search_dispensaries. It also implies a list-style tool by mentioning rows with excerpts and URLs, distinguishing it from 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 gives concrete when-to-use examples ('is brand X any good', 'best-tested flower', 'most terpene-rich vape'). It does not explicitly name alternatives or say when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up ANY New York OCM cannabis license number — retail dispensary, microbusiness, cultivator, processor, distributor, registered organization — against the full OCM licensing record (3,000+ licenses), not just shops. Returns the license type, status, holder, dates, county, and for cultivators the grow method; links the matching dispensary listing and brand when we have them. A partial number, application number, or company name returns candidates in similar. Use it to answer "is this a real licensed NY business" and "who holds this license".
| Name | Required | Description | Default |
|---|---|---|---|
| license_number | Yes | OCM license number (e.g. "OCM-CAURD-23-000023", "OCM-PROC-24-000096"), application number, or part of one; a company name also works |
| Name | Required | Description |
|---|---|---|
| brand | No | The brand catalog entry holding this license, when known |
| found | Yes | A license record matched exactly |
| source | No | Attribution line — CC BY 4.0, cite the row url |
| license | No | |
| message | No | |
| similar | No | Close matches when there is no exact one |
| licensed | Yes | found and the license status is Active |
| dispensary | No | The directory listing, when the license is a retail dispensary we list |
| dataUpdated | No | ISO timestamp of the underlying directory export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses meaningful behavior: it returns license type, status, holder, dates, county, grow method, and related dispensary/brand links, and it returns candidates in `similar` for partial input. This is useful context that annotations alone do not provide.
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 three focused sentences, front-loaded with the core scope and purpose. It packs coverage, return fields, partial-match behavior, and example use cases without redundant filler.
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 with an output schema, the description covers everything needed to select and invoke it correctly: scope, accepted input forms, returned data, linked results, and target questions. No critical guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the license_number parameter well, including example formats and that company names work. The description adds extra behavioral context by explaining that partial numbers or names return candidates in `similar`, which goes beyond the schema's static parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Look up ANY New York OCM cannabis license number" against the full OCM licensing record. It also explicitly differentiates scope by saying "not just shops," which separates it from the dispensary-focused sibling tools.
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 states clear use cases: "Use it to answer 'is this a real licensed NY business' and 'who holds this license'." It also signals its broad coverage versus shop-only tools, but it does not explicitly name sibling alternatives or list when to use them instead.
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_brand1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "availability": {
+ "additionalProperties": true,
+ "properties": {
+ "asOf": {
+ "type": "string"
+ },
+ "availableAt": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "byCity": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "crawledCategories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "dispensaryCount": {
+ "description": "Stores stocking the brand",
+ "type": "number"
+ },
+ "listedDispensaries": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ },
+ "tier": {
+ "description": "preview | full",
+ "type": "string"
+ }
+ },
+ "required": [
+ "dispensaryCount",
+ "availableAt"
+ ],
+ "type": "object"
+ },
+ "brand": {
+ "additionalProperties": true,
+ "properties": {
+ "certifications": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "childBrands": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "growType": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "dispensaryCount": {
+ "description": "Stores currently stocking the brand",
+ "type": "number"
+ },
+ "founded": {
+ "type": "number"
+ },
+ "growType": {
+ "description": "indoor | outdoor | mixed-light | combination (from OCM cultivator licenses)",
+ "type": "string"
+ },
+ "headquarters": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "isMSO": {
+ "type": "boolean"
+ },
+ "isMicrobusiness": {
+ "type": "boolean"
+ },
+ "isNewYorkBased": {
+ "type": "boolean"
+ },
+ "licenseNumber": {
+ "type": "string"
+ },
+ "licenseType": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "notableProducts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "parentBrand": {
+ "description": "Slug of the house brand that owns this one",
+ "type": "string"
+ },
+ "parentBrandName": {
+ "type": "string"
+ },
+ "parentBrandUrl": {
+ "type": "string"
+ },
+ "productCategories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "reviews": {
+ "description": "FindWeedNY reviews of this brand",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productType": {
+ "type": "string"
+ },
+ "rating": {
+ "type": "number"
+ },
+ "thcPct": {
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ },
+ "totalTerpenesPct": {
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "shortDescription": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "type": {
+ "description": "local | national | mso",
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "website": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "slug",
+ "url"
+ ],
+ "type": "object"
+ },
+ "dataUpdated": {
+ "description": "ISO timestamp of the underlying directory export",
+ "type": "string"
+ },
+ "found": {
+ "type": "boolean"
+ },
+ "message": {
+ "type": "string"
+ },
+ "source": {
+ "description": "Attribution line — CC BY 4.0, cite the row url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "found"
+ ],
+ "type": "object"
+}get_deals2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max deals per dispensary, default 6"New value: +"Max deals per dispensary, default 6, cap 10"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "dataUpdated": {
+ "description": "ISO timestamp of the underlying directory export",
+ "type": "string"
+ },
+ "found": {
+ "type": "boolean"
+ },
+ "message": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "deals": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "brand": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "lastSeenAt": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "originalPrice": {
+ "type": "number"
+ },
+ "price": {
+ "type": "number"
+ },
+ "productUrl": {
+ "type": "string"
+ },
+ "savingsPct": {
+ "type": "number"
+ },
+ "strainType": {
+ "type": "string"
+ },
+ "thcPct": {
+ "type": "number"
+ },
+ "weight": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "dispensary": {
+ "additionalProperties": true,
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "url"
+ ],
+ "type": "object"
+ },
+ "promotions": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "endDate": {
+ "type": "string"
+ },
+ "lastSeenAt": {
+ "type": "string"
+ },
+ "promoType": {
+ "type": "string"
+ },
+ "startDate": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalDeals": {
+ "type": "number"
+ },
+ "totalPromotions": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "dispensary",
+ "deals",
+ "promotions"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source": {
+ "description": "Attribution line — CC BY 4.0, cite the row url",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_dispensary1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "dataUpdated": {
+ "description": "ISO timestamp of the underlying directory export",
+ "type": "string"
+ },
+ "dispensary": {
+ "additionalProperties": true,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "amenities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "city": {
+ "type": "string"
+ },
+ "claimed": {
+ "type": "boolean"
+ },
+ "closure": {
+ "additionalProperties": true,
+ "description": "Present only when the shop has closed",
+ "properties": {
+ "announcedDate": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "temporary": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "county": {
+ "type": "string"
+ },
+ "dba": {
+ "description": "Legal entity name",
+ "type": "string"
+ },
+ "deliveryZipCodes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "distance": {
+ "description": "Miles from `near`, when a near point was given",
+ "type": "number"
+ },
+ "geocodeAccuracy": {
+ "type": "string"
+ },
+ "googleRating": {
+ "type": "number"
+ },
+ "googleReviewCount": {
+ "type": "number"
+ },
+ "hours": {
+ "additionalProperties": true,
+ "description": "Posted hours by weekday",
+ "properties": {},
+ "type": "object"
+ },
+ "hoursToday": {
+ "type": "string"
+ },
+ "id": {
+ "description": "OCM license number (directory id)",
+ "type": "string"
+ },
+ "isDeliveryOnly": {
+ "type": "boolean"
+ },
+ "isMedical": {
+ "type": "boolean"
+ },
+ "isMicrobusiness": {
+ "type": "boolean"
+ },
+ "lastVerified": {
+ "type": "string"
+ },
+ "latitude": {
+ "type": "number"
+ },
+ "licenseExpirationDate": {
+ "type": "string"
+ },
+ "licenseIssueDate": {
+ "type": "string"
+ },
+ "licenseType": {
+ "type": "string"
+ },
+ "longitude": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "description": "NYC neighborhood, when applicable",
+ "type": "string"
+ },
+ "offersDelivery": {
+ "type": "boolean"
+ },
+ "openNow": {
+ "description": "Open right now by posted hours (New York time); absent when hours are unknown",
+ "type": "boolean"
+ },
+ "operationalStatus": {
+ "description": "Active | Non-Operational | Unknown",
+ "type": "string"
+ },
+ "phone": {
+ "type": "string"
+ },
+ "retailDateOpened": {
+ "description": "YYYY-MM-DD the shop opened to the public",
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "tier": {
+ "description": "open | coming-soon | delivery-only",
+ "type": "string"
+ },
+ "url": {
+ "description": "findweedny.com page — cite this",
+ "type": "string"
+ },
+ "website": {
+ "type": "string"
+ },
+ "zipCode": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "url"
+ ],
+ "type": "object"
+ },
+ "found": {
+ "type": "boolean"
+ },
+ "message": {
+ "type": "string"
+ },
+ "source": {
+ "description": "Attribution line — CC BY 4.0, cite the row url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "found"
+ ],
+ "type": "object"
+}get_market_statsget_review1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "dataUpdated": {
+ "description": "ISO timestamp of the underlying directory export",
+ "type": "string"
+ },
+ "found": {
+ "type": "boolean"
+ },
+ "message": {
+ "type": "string"
+ },
+ "review": {
+ "additionalProperties": true,
+ "properties": {
+ "batch": {
+ "type": "string"
+ },
+ "brand": {
+ "type": "string"
+ },
+ "brandSlug": {
+ "type": "string"
+ },
+ "brandUrl": {
+ "type": "string"
+ },
+ "cannabinoids": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "pct": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "pct"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "coaUrl": {
+ "description": "Certificate of analysis",
+ "type": "string"
+ },
+ "cultivation": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "excerpt": {
+ "type": "string"
+ },
+ "price": {
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productType": {
+ "description": "flower | vape | concentrate | edible | accessory | dispensary",
+ "type": "string"
+ },
+ "productUrl": {
+ "type": "string"
+ },
+ "rating": {
+ "description": "1–5, FindWeedNY's opinion",
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "strain": {
+ "type": "string"
+ },
+ "terpenes": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "pct": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "pct"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "thcPct": {
+ "description": "Total THC ≈ THCa×0.877 + Δ9, from the COA",
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topTerpenes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "totalTerpenesPct": {
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "rating",
+ "url"
+ ],
+ "type": "object"
+ },
+ "source": {
+ "description": "Attribution line — CC BY 4.0, cite the row url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "found"
+ ],
+ "type": "object"
+}license_lookupmarket_statssearch_brands3 fields changedInput schema / properties / ny_based / descriptionAdded value: +"Only brands headquartered / grown in New York"Input schema / properties / type / descriptionAdded value: +"Brand type: local (NY), national, or multi-state operator"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "brands": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "certifications": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "dispensaryCount": {
+ "description": "Stores currently stocking the brand",
+ "type": "number"
+ },
+ "founded": {
+ "type": "number"
+ },
+ "growType": {
+ "description": "indoor | outdoor | mixed-light | combination (from OCM cultivator licenses)",
+ "type": "string"
+ },
+ "headquarters": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "isMSO": {
+ "type": "boolean"
+ },
+ "isMicrobusiness": {
+ "type": "boolean"
+ },
+ "isNewYorkBased": {
+ "type": "boolean"
+ },
+ "licenseNumber": {
+ "type": "string"
+ },
+ "licenseType": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "parentBrand": {
+ "description": "Slug of the house brand that owns this one",
+ "type": "string"
+ },
+ "productCategories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "shortDescription": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "type": {
+ "description": "local | national | mso",
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "slug",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "dataUpdated": {
+ "description": "ISO timestamp of the underlying directory export",
+ "type": "string"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "source": {
+ "description": "Attribution line — CC BY 4.0, cite the row url",
+ "type": "string"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "offset",
+ "brands"
+ ],
+ "type": "object"
+}search_dispensaries6 fields changedInput schema / properties / near / descriptionPrevious value: -"Filter/sort by distance from a point"New value: +"Filter/sort by distance from a point (results gain a `distance` in miles)"Input schema / properties / near / properties / lat / descriptionAdded value: +"Latitude in decimal degrees"Input schema / properties / near / properties / lng / descriptionAdded value: +"Longitude in decimal degrees (negative in New York)"Input schema / properties / near / properties / radius_miles / descriptionPrevious value: -"Default 25"New value: +"Search radius in miles, default 25"Input schema / properties / sort / descriptionAdded value: +"Default: relevance with a query, distance with near, otherwise name"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "brandAvailability": {
+ "additionalProperties": true,
+ "description": "Present when a brand filter was applied. Never conclude \"nobody carries it\" from an empty list — read knownDispensaries / inCity.",
+ "properties": {
+ "brand": {
+ "type": "string"
+ },
+ "inCity": {
+ "additionalProperties": true,
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "inCounty": {
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "county": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "knownDispensaries": {
+ "description": "How many stores actually stock the brand",
+ "type": "number"
+ },
+ "listedDispensaries": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ },
+ "tier": {
+ "description": "preview (public: ≤10 stores listed) | full (signed-in /mcp/full)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "brand",
+ "tier",
+ "listedDispensaries",
+ "knownDispensaries"
+ ],
+ "type": "object"
+ },
+ "dataUpdated": {
+ "description": "ISO timestamp of the underlying directory export",
+ "type": "string"
+ },
+ "dispensaries": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "city": {
+ "type": "string"
+ },
+ "closure": {
+ "additionalProperties": true,
+ "description": "Present only when the shop has closed",
+ "properties": {
+ "announcedDate": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "temporary": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "county": {
+ "type": "string"
+ },
+ "dba": {
+ "description": "Legal entity name",
+ "type": "string"
+ },
+ "distance": {
+ "description": "Miles from `near`, when a near point was given",
+ "type": "number"
+ },
+ "googleRating": {
+ "type": "number"
+ },
+ "googleReviewCount": {
+ "type": "number"
+ },
+ "hoursToday": {
+ "type": "string"
+ },
+ "id": {
+ "description": "OCM license number (directory id)",
+ "type": "string"
+ },
+ "isDeliveryOnly": {
+ "type": "boolean"
+ },
+ "isMedical": {
+ "type": "boolean"
+ },
+ "isMicrobusiness": {
+ "type": "boolean"
+ },
+ "latitude": {
+ "type": "number"
+ },
+ "licenseType": {
+ "type": "string"
+ },
+ "longitude": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "description": "NYC neighborhood, when applicable",
+ "type": "string"
+ },
+ "offersDelivery": {
+ "type": "boolean"
+ },
+ "openNow": {
+ "description": "Open right now by posted hours (New York time); absent when hours are unknown",
+ "type": "boolean"
+ },
+ "operationalStatus": {
+ "description": "Active | Non-Operational | Unknown",
+ "type": "string"
+ },
+ "phone": {
+ "type": "string"
+ },
+ "retailDateOpened": {
+ "description": "YYYY-MM-DD the shop opened to the public",
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "tier": {
+ "description": "open | coming-soon | delivery-only",
+ "type": "string"
+ },
+ "url": {
+ "description": "findweedny.com page — cite this",
+ "type": "string"
+ },
+ "website": {
+ "type": "string"
+ },
+ "zipCode": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "notes": {
+ "description": "Caveats about the filters applied",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "source": {
+ "description": "Attribution line — CC BY 4.0, cite the row url",
+ "type": "string"
+ },
+ "total": {
+ "description": "Matches before paging",
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "offset",
+ "dispensaries"
+ ],
+ "type": "object"
+}search_reviews3 fields changedInput schema / properties / cultivation / descriptionAdded value: +"How the flower was grown, when the review records it"Input schema / properties / product_type / descriptionAdded value: +"Kind of product reviewed"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "dataUpdated": {
+ "description": "ISO timestamp of the underlying directory export",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "reviews": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "brand": {
+ "type": "string"
+ },
+ "brandSlug": {
+ "type": "string"
+ },
+ "brandUrl": {
+ "type": "string"
+ },
+ "coaUrl": {
+ "description": "Certificate of analysis",
+ "type": "string"
+ },
+ "cultivation": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "excerpt": {
+ "type": "string"
+ },
+ "price": {
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productType": {
+ "description": "flower | vape | concentrate | edible | accessory | dispensary",
+ "type": "string"
+ },
+ "rating": {
+ "description": "1–5, FindWeedNY's opinion",
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "strain": {
+ "type": "string"
+ },
+ "thcPct": {
+ "description": "Total THC ≈ THCa×0.877 + Δ9, from the COA",
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topTerpenes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "totalTerpenesPct": {
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "rating",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source": {
+ "description": "Attribution line — CC BY 4.0, cite the row url",
+ "type": "string"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "offset",
+ "reviews"
+ ],
+ "type": "object"
+}verify_licenseget_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!
