FindWeedNY

Define a cannabis term

define_term

Read-only

FindWeedNY's cannabis glossary: ~300 terms for products (live rosin, badder, distillate), cannabinoids and terpenes (THCA, total THC, myrcene), lab testing and COAs (LOQ, action limit, remediation), contaminants (pesticides, solvents, heavy metals, mycotoxins), New York law (CAURD, microbusiness, possession limits, home grow) and shop slang (420, eighth, preroll). Each definition is written for New York, cites primary sources for legal claims, and many carry an "In New York" note and buying tips. Lab terms carry counts from tens of thousands of New York certificates of analysis (how often an analyte is tested, detected, and failed). Pass a term, alias, or misspelling; an exact match returns the full entry, otherwise the closest terms come back in matches. Use it for "what is X", "what does X on my label mean", or "is X legal in New York" questions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "term": "<term>"
    },
    "name": "define_term"
  }
}

Input Schema

Name	Required	Description	Default
`term`	Yes	The word or phrase, e.g. "THCA", "live resin", "LOQ", "CAURD"
`limit`	No	Max alternative matches, default 5, cap 10

Output Schema

Name	Required	Description
`term`	No
`found`	Yes
`source`	No	Attribution line — CC BY 4.0, cite the row url
`matches`	No	Closest terms when there is no exact match, or other senses when there is
`message`	No
`dataUpdated`	No	ISO timestamp of the feed this result came from: dispensary directory (OCM refresh), deals export, brand-availability export, or review index

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, and the description adds real behavior beyond that: an exact match returns the full entry, otherwise the closest terms come back in `matches`. It also discloses corpus provenance (primary-source citations for legal claims, test/detect/fail counts from New York COAs). It does not describe result size, pagination, or what a `matches` entry contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with what the glossary contains and back-loaded with the usage intents and match behavior, so an agent gets the key facts early. The middle taxonomy sentence is dense and example-heavy, but each example disambiguates coverage, so little is truly wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shape need not be explained, and the description still covers corpus scope, sourcing, fuzzy-match fallback, and the `limit` behavior. For a read-only lookup tool with only a readOnlyHint annotation, nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented; the description still adds meaning by stating that aliases and misspellings are acceptable inputs and that a non-exact term degrades to a `matches` list rather than erroring. That is genuine semantic value beyond the schema's bare 'The word or phrase'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (a ~300-term New York cannabis glossary) and enumerates the exact concept categories it covers — products, cannabinoids, lab/COA, contaminants, state law, slang. Combined with the tool name it is unambiguous what a call returns, and the sibling tools (dispensaries, brands, deals, licenses) are clearly a different domain, so no differentiation is needed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It closes with three concrete query intents: 'what is X', 'what does X on my label mean', and 'is X legal in New York'. That is strong when-to-use guidance. It stops short of explicit exclusions (e.g., 'do not use for locating a dispensary — use search_dispensaries'), though the sibling domains are already disjoint.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All FindWeedNY tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?