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., "@tractive-mcp where is my dog right now?"
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 for the Tractive GPS pet tracker. Lets AI assistants like Claude query your pet's location, tracker status, position history, and more.
Python 3.13+
A Tractive account with at least one GPS tracker
Related MCP server: GC-MCP
# Authenticate
uvx tractive-mcp auth
# Add to Claude Code
claude mcp add tractive -- uvx tractive-mcpgit clone https://github.com/rexchoppers/tractive-mcp.git
cd tractive-mcp
uv sync
uv run tractive-mcp auth
claude mcp add tractive -- uv run tractive-mcpTractive does not provide any OAuth mechanisms. As a result, email and passwords have to be stored locally. Run the auth command to save your Tractive credentials:
uvx tractive-mcp authCredentials are stored at ~/.config/tractive-mcp/credentials.json with 0600 permissions.
claude mcp add tractive -- uvx tractive-mcpAdd to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"tractive": {
"command": "uvx",
"args": ["tractive-mcp"]
}
}
}Tool | Description |
| Lists all pets on the account with their name, type, and device_id |
Tool | Description |
| Current GPS coordinates, speed, altitude, accuracy |
| Distance in metres from the pet's home location |
| Position history with summary stats (distance, bounding box, point count). Set |
Tool | Description |
| Battery level, charging state, connection state, firmware |
| Turn the tracker buzzer on/off |
| Turn the tracker LED on/off |
| Toggle live tracking mode (more frequent GPS, more battery) |
Tool | Description |
| Full pet profile — breed, weight, birthday, activity goals |
Tool | Description |
| All-in-one emergency tool. Returns location, distance from home, tracker status, and recent activity. Optionally activates live tracking, buzzer, and LED |
src/tractive_mcp/
server.py — MCP server, tool definitions, auth CLI
client.py — Credential management, Tractive client helper
models.py — Response dataclassesSee LICENSE.
Get how far a pet currently is from its home location.
Args: device_id: The device_id from list_pets.
Returns distance in metres, plus the home and current coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns distance in metres plus coordinates. However, it omits details such as whether a home location must be configured, how recent the 'current' data is, or any error conditions.
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 very concise, with three short lines covering purpose, argument, and return value. No superfluous 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?
Given the tool's simplicity (1 param, no output schema), the description covers the essential return values (distance and coordinates). It could be improved by noting units for coordinates and handling of missing home location, but it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds key semantic context: the 'device_id' parameter is explained as 'The device_id from list_pets', which guides the agent on provenance and value source—beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'how far a pet currently is from its home location'. It distinguishes from siblings like 'get_pet_location' which likely returns raw coordinates, not computed distance.
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 mentions that 'device_id' comes from 'list_pets', providing some prerequisite context. However, it does not explicitly guide when to use this tool versus alternatives like 'get_pet_location' or 'get_recent_positions', nor does it specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current GPS location of a pet.
Args: device_id: The device_id from list_pets.
Returns lat, lon, speed, altitude, time, and other position data.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It implies a read operation and lists return fields, but does not explicitly state that it is harmless or describe any constraints such as rate limits or authorization requirements.
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 extremely concise, using a clear one-line purpose and a brief docstring for the parameter and return values. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the essential inputs and outputs. It lists return fields (lat, lon, speed, etc.) and explains the parameter source. Missing error cases or permissions, but adequate for typical usage.
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 parameter device_id has no schema description (0% coverage), but the description adds value by specifying that it comes from list_pets, providing source guidance beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the current GPS location of a pet, using a specific verb and resource. It distinguishes from siblings like get_pet_distance_from_home and get_recent_positions.
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 by explaining that the device_id comes from list_pets, implying a prerequisite. However, it does not explicitly state when to use this tool versus alternatives like get_recent_positions or get_tracker_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full profile of a pet including breed, weight, birthday, and activity goals.
Args: device_id: The device_id from list_pets.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It only states the tool returns profile data without mentioning side effects, authentication needs, or error handling. The read-only nature is implied but not explicit.
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 extremely concise, consisting of one sentence and an arg list. Every word adds value, with no unnecessary repetition or 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?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic purpose and argument source. However, it omits full return field list, error scenarios, and pagination or formatting details. Adequate but not comprehensive.
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 has zero description coverage. The description adds minimal value by stating the device_id should come from list_pets, but does not explain format, validation, or constraints. For one parameter, this is adequate but not exceptional.
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 retrieves a pet's full profile including specific fields (breed, weight, birthday, activity goals). The verb 'Get' and resource 'pet profile' are specific, and it distinguishes from sibling tools like get_pet_location which returns location data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using list_pets to obtain device_id by stating 'The device_id from list_pets.' However, no explicit guidance on when to use this tool over siblings or when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent position history (breadcrumb trail) for a pet.
Args: device_id: The device_id from list_pets. hours: How many hours of history to fetch (default 24). include_points: If True, include the full list of position points. Set to False (default) to save context when you only need stats.
Returns a summary with point count, total distance, time range, and bounding box. If include_points is True, also returns the points array.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | ||
| hours | No | ||
| include_points | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool returns a summary (point count, distance, time range, bounding box) and optionally the points array. It does not discuss side effects, permissions, or idempotency, but the behavior is adequately transparent for a read-only data retrieval 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 description is concise (a few lines) and well-structured with clear Args and Returns sections. Every sentence adds value, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the return value (summary fields and optional points). For a tool with 3 parameters and clear context, the description is complete and leaves no significant gaps.
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 has 0% description coverage, but the description adds rich meaning: it explains device_id (from list_pets), hours (default 24), and include_points (default False, with guidance to save context). This goes well beyond the schema and helps the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get recent position history (breadcrumb trail) for a pet,' specifying the verb (get), resource (position history), and scope (recent). It distinguishes from siblings like get_pet_location (current location) and get_pet_distance_from_home by indicating historical trail data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage (retrieving historical position data) and implies when to use it (when history is needed). However, it does not explicitly exclude alternatives or state when not to use this tool versus siblings like get_pet_location.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of a Tractive GPS tracker.
Args: device_id: The device_id from list_pets.
Returns battery level, charging state, connection state, and hardware info.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It describes the output (battery, charging, connection, hardware info) and implies read-only behavior but does not mention any side effects, error states, or rate limits.
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 very concise with two short paragraphs: one sentence for purpose, then args and returns. No unnecessary words.
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 query tool with one parameter and no output schema, the description provides purpose, input source, and output fields. It is adequate but could optionally detail output format or error cases.
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 description adds meaning to the single parameter 'device_id' by specifying it comes from list_pets, which is not in the schema. This compensates for the 0% schema description coverage.
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 'Get the status of a Tractive GPS tracker' with a specific verb and resource. It distinguishes from sibling tools like get_pet_location or get_pet_profile by focusing on tracker hardware status.
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 that device_id comes from list_pets, providing implicit guidance on prerequisite. However, there is no explicit mention of when not to use this tool or alternatives, which limits decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all pets on the user's Tractive account.
Returns each pet's id, name, pet type (dog/cat), and assigned tracker id. Use the pet's id when calling other tools like get_pet_location.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It declares a read operation and lists return fields, but does not discuss authentication requirements, error conditions, or pagination. This is adequate but not exceptional.
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 concise at two sentences, front-loading the main action ('List all pets') and immediately providing useful context (returned fields and follow-up usage). Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description need not fully explain return values, but it does summarize key fields. It lacks mention of potential limits or pagination, but for a simple list with no parameters, this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by detailing the output, enabling the agent to understand what information will be available without needing to inspect the output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all pets on the user's account and specifies the returned fields (id, name, pet type, tracker id). This distinguishes it from sibling tools like get_pet_location which require a pet id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the returned pet id with other tools (e.g., get_pet_location), providing clear when-to-use guidance. It does not mention when not to use it, but for a listing tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emergency tool — call when a pet is lost or missing.
Gathers all critical info in one call: current location, distance from home, tracker battery/connection status, and recent movement summary. Can activate live tracking, buzzer, and LED on the tracker.
Args: device_id: The device_id from list_pets. enable_live_tracking: Turn on live tracking for frequent GPS updates (default True). enable_buzzer: Turn on the tracker buzzer to help locate the pet nearby (default False). enable_led: Turn on the tracker LED light (default False).
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | ||
| enable_live_tracking | No | ||
| enable_buzzer | No | ||
| enable_led | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It describes what the tool does (gathers info, activates features) but does not disclose exact side effects, return values, or behavior beyond parameter defaults.
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?
Description is concise with two well-structured paragraphs: one for purpose and one for parameters. No redundant information, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description covers purpose and parameters but lacks information about the return value or what the agent can expect after invocation. This gap leaves some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed explanations for each parameter, including purpose and defaults (e.g., device_id from list_pets).
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 defines the tool as an emergency tool for lost pets, specifying it gathers critical info and can activate tracking/buzzer/LED. It distinguishes itself from siblings by combining multiple functions into one call.
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 explicitly states 'Emergency tool — call when a pet is lost or missing', providing clear usage context. It implies comprehensiveness without explicitly excluding alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn the tracker buzzer on or off.
Args: device_id: The device_id from list_pets. active: True to turn on, False to turn off.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | ||
| active | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the on/off behavior and parameter semantics but lacks details on side effects, permissions, or return value. Since annotations are absent, the description carries the full burden, and it provides only minimal behavioral context.
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 highly concise with two clear sentences and an args list. Every element is necessary and front-loaded, with no wasted words.
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 on/off tool lacking an output schema, the description covers the function and parameters adequately. It does not specify return behavior, but given the tool's simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful parameter context: 'device_id: The device_id from list_pets' and 'active: True to turn on, False to turn off'. This clarifies the source and effect beyond type-only schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool turns the tracker buzzer on or off, specifying the verb 'turn' and resource 'tracker buzzer'. However, it does not differentiate from sibling tools like set_led or set_live_tracking, which have similar patterns.
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?
No guidance is provided on when to use this tool versus alternatives. For instance, it does not explain scenarios for turning the buzzer on/off compared to set_led or set_live_tracking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn the tracker LED light on or off.
Args: device_id: The device_id from list_pets. active: True to turn on, False to turn off.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | ||
| active | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately states the core behavior (turning LED on/off) but provides no additional behavioral context such as side effects, permissions, or rate limits. Since no annotations are present, the description carries the full burden, and it is minimally adequate.
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?
Extremely concise: one sentence for purpose, then two lines for args. No wasted words, and the structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple binary setter tool with no output schema, the description covers purpose and parameters completely. No missing necessary details given the tool's complexity.
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 description explains both parameters: device_id comes from list_pets, and active expects True/False. This adds value beyond the schema (which has no descriptions), compensating for the 0% schema coverage.
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 action ('Turn on or off') and the resource ('tracker LED light'), which distinguishes it from siblings like set_buzzer or set_live_tracking.
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?
No explicit guidance on when to use this tool versus alternatives such as set_buzzer or set_live_tracking. It does indicate that device_id comes from list_pets, implying a prerequisite, but lacks when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn live tracking mode on or off. Live tracking gives more frequent GPS updates but uses more battery.
Args: device_id: The device_id from list_pets. active: True to turn on, False to turn off.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | ||
| active | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It mentions the trade-off of more battery usage, which is useful behavioral context. However, it does not describe what happens when toggling (e.g., delay, effect on other features) or error conditions. Still above average.
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 and a parameter list. Front-loaded with the main action. Every sentence provides necessary information. No fluff.
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 toggle with no output schema, the description covers the essentials: what it does, the parameters, and a key trade-off. Missing potential return value or error handling, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains that device_id comes from list_pets and active means True to turn on, False to turn off. This adds value beyond the schema's basic types. Could be improved by noting validation or default behavior.
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?
Clearly states the verb 'turn on or off' and the resource 'live tracking mode'. Distinguishes from sibling tools like get_tracker_status, get_pet_location, etc., which are for reading rather than modifying state.
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?
Implied usage: to enable or disable live tracking. No explicit when-to-use vs alternatives (e.g., checking current status with get_tracker_status first) or when-not-to-use (e.g., if battery is low). Lacks guidance on prerequisites or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose: listing pets, retrieving location, distance, profile, history, status, emergency info, and controlling buzzer/LED/live tracking. No two tools overlap in functionality.
Most tools follow a consistent verb_noun pattern (e.g., list_pets, get_pet_location, set_buzzer). The 'lost_pet' tool uses an imperative verb without underscore but is still clear and fits the domain's emergency context.
10 tools is an appropriate number for a pet tracking server. Each tool serves a necessary function without excess, covering core operations like retrieving location, history, status, and controlling tracker features.
The tool set covers the full lifecycle for pet tracking: listing pets, retrieving location, distance, history, profile, tracker status, and toggling live tracking/buzzer/LED. The lost_pet tool bundles critical info for emergencies. No obvious gaps for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give any AI assistant real-time access to your phone's GPS and location history.
Control your Tesla from your AI assistant - climate, charging, access, and security.
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
Query your Twitch streams, events, supporters, raids & rankings from an AI assistant via OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rexchoppers/tractive-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server