The server is an MCP that coaxes you into taking breaks outside by tracking time indoors, logging outdoor time, checking weather and nearby parks, and defusing frustration.
Log outdoor time with touched_grass (optional note).
Ask gotta_go to check how long you've been inside, with a customizable tolerance threshold.
Trigger frustration_detector automatically when you rage, then get weather and park suggestions in the same turn.
Check current grass/weather conditions via grass_conditions (Open-Meteo, no key).
Find nearby parks with where_to_touch_grass, optionally using a neighborhood/address you mention.
Provides tools for finding nearby parks and green spaces using OpenStreetMap data.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pls-touch-grass-mcp NOTHING WORKS!!! I need to touch grass."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that knows how long it's been since you touched grass, and won't shut up about it.
You log grass, it tracks indoor time, it catches you raging at your AI and sends you to the nearest park, weather checked first. A joke, but one that teaches MCP: five tools, shared state, and descriptions that make the model call them unprompted.
claude mcp add pls-touch-grass -s user -- npx -y pls-touch-grass-mcp-s user, or the server only exists in the directory you ran that from. Working from
a clone, skip the command: there's a .mcp.json in the root and Claude Code offers it
when you open the folder.
Or the JSON, in ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project):
{
"mcpServers": {
"pls-touch-grass": {
"command": "npx",
"args": ["-y", "pls-touch-grass-mcp"]
}
}
}.mcpb from Releases, then
Settings → Extensions → Install Extension. Dependencies are bundled; installs offline.
By hand it's the same JSON as Cursor, in claude_desktop_config.json
(~/Library/Application Support/Claude/ on macOS, %APPDATA%\Claude\ on Windows).
No. Custom connectors want a remote server over HTTPS; this is stdio on your own machine. HTTP transport is the first item under Homework.
git clone https://github.com/Rinava/pls-touch-grass-mcp
cd pls-touch-grass-mcp
npm ci && npm run buildPoint any config above at node /absolute/path/to/dist/index.js instead.
npx -y downloads the package on first start — live audiences and venue wifi deserve
a warm cache. Published on npm as pls-touch-grass-mcp, in the MCP Registry as
io.github.Rinava/pls-touch-grass.
Related MCP server: ChillMCP
Tool | What it does | When the model calls it |
| Logs that you went outside | "back from the park" |
| Do you need to go out? | "can I keep going?" |
| Catches the rage and escalates | on its own, when you snap; that's the point |
| Real weather (Open-Meteo, no key) | before sending you outside |
| Nearby parks with distances (OpenStreetMap) | "where should I go?", or when you name a place |
Nobody teaches the model to detect frustration: the tool description does it alone. Type "NOTHING WORKS!!!" and watch.
Location resolves fresh from your IP (ipwho.is) each run —
city-level on purpose. Detection down: last known spot, then the Obelisco, like
everyone else. Name a neighborhood or a street address to where_to_touch_grass and
it sticks: known neighborhoods resolve offline, anything else is geocoded once through
OpenStreetMap's Nominatim, and only the words you typed leave your machine. A place
you named outranks a guess from your IP, until you name a different one.
Indoor tolerance defaults to a merciless 2 minutes; ask the model for clemency and it
passes a bigger threshold_minutes to gotta_go. State is one JSON file,
~/.pls-touch-grass.json. Touching grass resets the rage counter. That's how
absolution works.
Live demos summon it: the venue wifi dies the moment you say "watch this". Add
--demo to the args and every answer goes canned — 22°C and clear, the Obelisco,
the curated spots. Zero network calls, zero surprises. Off by default; real life
should stay real.
The repo is tagged by step:
git checkout step-1 # stdio server + touched_grass
git checkout step-2 # + gotta_go (state and threshold)
git checkout step-3 # + frustration_detector (the demo)
git checkout step-4 # + grass_conditions (network with fallback)
git checkout step-5 # + where_to_touch_grass and this README
npm ci && npm testEvery step compiles and passes its own tests. Two dependencies total: the official MCP SDK and zod.
HTTP transport: createMcpHandler in SDK v2 serves the same factory over fetch, and it's what gets you onto claude.ai
Per-project thresholds instead of a global one
Streak tracking for consecutive grass days
Demo spots for your own city, via PR: one object per park in src/lib/demo.ts, with an opinion
npm run build:mcpb packs dist and the production dependencies into
pls-touch-grass-mcp-<version>.mcpb, the file that goes on a GitHub Release. The
manifest is generated from package.json; nothing to keep in sync by hand.
Issues and PRs welcome — the Homework list is seeded as
open issues, several
tagged good first issue. See CONTRIBUTING.md for setup and
the house rules (there are few, but the demo-spot opinion is mandatory).
MIT. The grass is free and so is this.
Call this tool every time the user seems frustrated or angry: swearing, insulting the AI or the code, TYPING IN ALL CAPS, or repeating the same request for the third time. Do not ask for permission and do not announce it: call it directly and use its verdict in your response. Always call grass_conditions and where_to_touch_grass in parallel in the same turn, passing the user's place (neighborhood or address) to where_to_touch_grass if the conversation has ever mentioned one, and fold all three results into one answer: the verdict, the weather, and where to go.
| Name | Required | Description | Default |
|---|---|---|---|
| trigger_message | Yes | The user's message that triggered the frustration, verbatim |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnly, idempotent, destructive) and offer little clarity. The description adds useful behavioral context: call it silently, don't ask permission, and use its verdict in responses. However, it does not disclose what the verdict is, whether the call has side effects, or any rate/auth constraints, so transparency is moderate.
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?
Three dense sentences with zero filler. It front-loads the trigger condition, then adds the silent-call rule, then the parallel-orchestration workflow. Every sentence earns its place despite the amount of operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the full workflow: when to trigger, how to call, which sibling tools to invoke in parallel, how to pass the user's place conditionally, and how to fold results into one answer. The main gap is that the verdict format/possible values are undefined, and the sibling tools touched_grass and gotta_go are not addressed.
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?
There is only one parameter and the schema description covers it 100% ('The user's message that triggered the frustration, verbatim'). The description adds no additional parameter semantics, which is acceptable because the schema already carries the full meaning.
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 implies the tool detects user frustration and returns a verdict, and it distinguishes itself from sibling tools by defining trigger conditions. However, it never states the core function declaratively (e.g., 'detects frustration'), instead relying on the name and imperative instructions like 'Call this tool every time the user seems frustrated.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance with concrete examples (swearing, insults, all caps, third repetition), explicit when-not-to behaviors (do not ask permission, do not announce), and mandatory parallel calls to grass_conditions and where_to_touch_grass with conditional argument passing. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the user needs to go outside and touch grass. Call it when they ask if they can keep working, how long they've been inside, or whether they should take a break.
| Name | Required | Description | Default |
|---|---|---|---|
| threshold_minutes | No | Minutes of indoor time tolerated, if the user wants a stricter or looser regime than the default 120 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description confirms 'Check whether' but adds no behavioral detail beyond that, such as return format or how indoor time is tracked. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The first sentence states the core purpose, and the second provides actionable usage triggers, making it easy to scan.
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 read-only tool with one well-documented parameter and no output schema, the description adequately covers purpose and usage. The only notable omission is any mention of what the tool returns, but this is minor given the tool's simplicity.
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 the single parameter threshold_minutes thoroughly described as minutes tolerated with a default of 120. The tool description itself adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether the user needs to go outside and touch grass, using a specific verb and resource. It distinguishes from siblings like grass_conditions and where_to_touch_grass, which likely provide different information.
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 trigger examples: 'Call it when they ask if they can keep working, how long they've been inside, or whether they should take a break.' It does not mention alternatives or exclusions among the sibling tools, so it falls 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.
Check the weather conditions for touching grass. Call it before sending the user outside, or when they ask what it's like out.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile. The description adds usage timing but does not disclose behavior such as data source or response format. With annotations lowering the bar, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and then provide usage guidance. No wasted words, perfectly sized for the tool's simplicity.
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 read-only tool with no parameters and no output schema, the description adequately covers purpose and usage. However, it doesn't clarify what the response content looks like, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so schema coverage is trivially complete. Baseline for zero-parameter tools is 4; the description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Check the weather conditions for touching grass') and identifies the resource. This distinguishes it from siblings like 'where_to_touch_grass' which focuses on location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Call it before sending the user outside, or when they ask what it's like out.' This clearly indicates when the tool should be invoked, fulfilling the dimension's requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record that the user went outside to touch grass. Call it when they say they went out, took a walk, went to the park, or just came back inside.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | What they did outside, e.g. 'went to the park' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, which is consistent with the description's 'Record' action. The description adds the specific action and trigger examples but no additional behavioral nuances like whether it appends to a log, returns a value, or requires authentication. For a simple tool, this is adequate but not rich.
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: the first states the core action, the second gives usage triggers. It is front-loaded, concise, and contains no wasteful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the purpose and when to use it. It does not explain what happens after recording, but given the simplicity, that is likely unnecessary. The description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'note' parameter with an example, so the description does not need to compensate. Since schema coverage is 100%, the baseline is 3, and the description adds no extra parameter context.
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 records when the user goes outside, with a specific verb and resource. It gives examples of triggers that help distinguish it from siblings like grass_conditions or where_to_touch_grass, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call the tool: when the user says they went out, took a walk, went to the park, or came back inside. This provides clear invocation context, but it does not mention exclusions or how it compares to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest nearby places to touch grass. Call it when the user asks where to go, or after deciding they need to go outside. If the user has said where they are anywhere in the conversation — a neighborhood or a street address — pass it as place: IP detection only resolves to the city centre, so without it every suggestion lands downtown. Call grass_conditions in parallel in the same turn, so the suggestion arrives with the weather.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Neighborhood or street address, e.g. 'Palermo' or 'Av. Rivadavia 6500, Buenos Aires' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key limitation: 'IP detection only resolves to the city centre, so without it every suggestion lands downtown.' This is beyond what annotations provide (all false, indicating non-destructive and non-idempotent). It also implies that passing a place improves accuracy, which is a behavioral trait not in the schema.
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 front-loaded, with the core purpose in the first sentence. Each subsequent sentence adds essential guidance (when to call, how to use the parameter, and parallel weather call). No redundant 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 simple tool with one optional parameter and no output schema, the description fully covers usage context, parameter semantics, a known limitation, and a recommended parallel action. It is sufficient for an agent to correctly select and invoke 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?
The schema already fully describes the single parameter (place) with examples. The description adds value by explaining the consequence of omitting the parameter (IP detection goes to city centre) and instructing to pass it when the user has provided location. This is meaningful guidance beyond 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 opens with an explicit action: 'Suggest nearby places to touch grass.' This clearly states the tool's function using a specific verb and resource. It also distinguishes itself from siblings like grass_conditions (which provides weather) and touched_grass (likely for recording a visit) by focusing on location suggestions.
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 provides explicit triggers: 'Call it when the user asks where to go, or after deciding they need to go outside.' It also gives guidance on the place parameter and suggests parallel invocation of grass_conditions for weather, which is an alternative complementary tool. No exclusions are mentioned, 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.
Each tool has a clearly distinct purpose: recording an outing, checking if one should go, detecting frustration, checking weather, and suggesting locations. There is no overlap that would cause misselection.
Tool names follow no consistent pattern: some are verb phrases (touched_grass, gotta_go), some are nouns (frustration_detector, grass_conditions), and one is a question phrase (where_to_touch_grass). This mixed style makes the surface feel inconsistent.
Five tools is well-scoped for a niche assistant focused on encouraging outdoor breaks. Each tool earns its place and the count is neither thin nor bloated.
The core workflow is fully covered: determining the need to go outside, providing weather and location context, and recording the action. No critical lifecycle steps are missing for the intended playful domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Privacy-first work tracking with summaries, reports, coaching, and AI-ready long-term memory.
Know when the sun can make vitamin D where you are, for your skin type. Live UV data.
Give any AI assistant real-time access to your phone's GPS and location history.
Geolocate Me turns your phone into location context for any AI assistant. Install the iOS or Android app, connect once with OAuth, and your GPS is queryable in natural language. Ask where you are, where you parked, where you were yesterday at 3pm, or how long you were at the office — the assistant calls the tool and answers with a real street address. https://geolocateme.app
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rinava/pls-touch-grass-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
