Persome MCP Serverofficial
A
licenseNot graded
qualityA
maintenanceEnables MCP agents to query a local, cross-app personal model built from macOS activity, providing search, receipts, and model tools.
1,321
Apache 2.0
availability_mcp
by shayben
Click on "Deploy 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., "@availability_mcpcheck if the user has been idle for 5 minutes"
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.
availability_mcp
A dependency-free MCP server that runs locally and reports the current user's activity/idle state. Agents can use it when deciding whether to wait for user feedback or continue autonomously. Activity data stays on-device and is only returned to the connected MCP client.
Install and configure
Python 3.10 or newer is required.
python -m pip install .Add the server to your MCP client:
{
"mcpServers": {
"availability": {
"command": "availability-mcp"
}
}
}For development, run it directly with:
PYTHONPATH=src python -m availability_mcp.serverRelated MCP server: roxabi-sense
Tool
get_user_activity
Returns:
idle_seconds: time since the last detected user inputis_idle: whether idle time meetsidle_threshold_seconds(default: 300)last_activity_atandobserved_at: UTC ISO 8601 timestampssource: the operating-system API used for the reading
The optional idle_threshold_seconds argument must be non-negative.
Platform support
Windows:
GetLastInputInfomacOS: the built-in
ioregutility andIOHIDSystemLinux:
xprintidlewhen installed, otherwise systemd-logind's user idle hint. Desktop environments that publish neither source return a tool error rather than guessing.
On macOS, terminal input-monitoring permissions may be required. Linux
systemd-logind reports coarse active/idle state when xprintidle is not
available; install xprintidle under X11 for exact idle duration.
Test
PYTHONPATH=src python -m unittest discover -s testsAvailable Tools
1 toolget_user_activityA
Get the local user's current idle duration and activity state. Use this to decide whether to wait for user feedback or proceed autonomously.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| idle_threshold_seconds | No | Idle duration at which is_idle becomes true. |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only operation ('Get the local user's current idle duration') but does not explicitly state whether it's read-only, whether it requires permissions, or how the state is determined. The usage guidance adds some value, but key behavioral traits remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the tool's purpose and followed by actionable guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description covers the purpose and usage context well. However, without annotations, it could more explicitly state that it is a safe read operation or describe what the activity state values represent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is fully documented in the schema ('Idle duration at which is_idle becomes true.'). The description does not add meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('local user's current idle duration and activity state'), making the tool's output clear. No sibling tools exist, so sibling differentiation isn't required, but the description could be slightly more precise about the return shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Use this to decide whether to wait for user feedback or proceed autonomously.' This tells the agent when the tool is relevant, though it doesn't describe when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
get_user_activity
TDQS
A3.9/5.0
Scored across 1 tool
Disambiguation5/5
There is only one tool, so there is no possibility of confusion or misselection between tools. Its purpose (retrieving the local user's idle duration and activity state) is unambiguous.
Naming Consistency5/5
The single tool follows a clear verb_noun convention (get_user_activity). With only one tool there is no inconsistency to introduce.
Tool Count3/5
A single tool is thin for a server, even one with a narrow scope like availability detection. It works but leaves little room for related queries, making the surface feel minimal.
Completeness4/5
For the narrow stated purpose of determining user availability, the tool covers the key signal (idle duration and activity state). Coverage is reasonable, though richer availability context (e.g. session or lock state) is absent.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
A paid remote MCP for AI SDK data query MCP, built to return verdicts, receipts, usage logs, and aud
A paid remote MCP for AI agent browser DevTools MCP, built to return verdicts, receipts, usage logs,
A paid remote MCP for AI agent browser approval MCP, built to return verdicts, receipts, usage logs,
Remote MCP for AI Studio Android release gate MCP, structured receipts, audit logs, and reviewer-rea
Related MCP Servers
roxabi-senseofficial
AlicenseBqualityBmaintenanceLocal workstation attention journal that tracks focus, idle, and agent sessions, exposing timeline data via MCP for AI agents to query current or past activity.5AGPL 3.0- FlicenseAqualityCmaintenanceEnables agents to display status readouts in the Mac's notch area via MCP, with multiple styles and progress indicators.51-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to send notifications to a unified feed, report activity, request input from humans, and manage notification state through MCP tools.4MIT