Location Memory

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct query: current location, stay lists, city/country rollups, place rankings, trip lists/details, people links, day timeline, stats, records, home timeline, data coverage, and raw SQL. The boundaries are clear from the descriptions, so an agent can reliably select the right tool.
Naming Consistency3/5
Tool names are all snake_case and readable, but they mix simple nouns (stays, trips, day, home) with compound descriptors (cities_visited, who_was_there, location_coverage). There is no consistent verb_noun or prefix pattern, though this inconsistency does not prevent comprehension.
Tool Count5/5
With 14 tools, the set is well-scoped for a location memory server. Each tool earns its place by covering a distinct query type, and the count falls within the ideal 3-15 range.
Completeness5/5
The tool surface is thoroughly complete for its domain: current status, lists, aggregates, details, stats, extremes, home timeline, coverage gaps, and a raw SQL escape hatch. There are no obvious dead ends for common location-history questions.
Average 4/5 across 14 of 14 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the trip definition and that hand-edited names are kept, which is useful. However, it does not disclose whether this is a read-only operation, how filtering interacts with the definition (e.g., country filter perhaps overrides the 100km rule), or behavior like default limits beyond 'Default 40' in schema.
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?
Description is two sentences, front-loaded with the most important usage info (newest first, fields), then the trip definition. It is compact, though it could be tighter by omitting the list of fields already implied by output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter list tool with 100% schema coverage and no output schema, the description is average. It defines 'trip' and indicates hand-edited names, but doesn't clarify relationships with siblings like 'trip' or 'stays', nor what happens when filters conflict with the trip definition. Enough to select the tool, but gaps remain.
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% with good parameter descriptions, so baseline is 3. The tool description adds meaningful context: 'newest first', the trip definition (outside country or >100 km) that underpins 'min_nights' and filters, and the note about hand-edited names. This exceeds the baseline.
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?
The description says it returns trips with specific fields (name, dates, nights, ...) and is newest first, which is a specific verb+resource. It distinguishes from siblings like 'trip' (singular) partly by being a list, but doesn't explicitly contrast with 'stays' or 'travel_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening line implies a list of all trips with optional filters, but there's no explicit 'when to use' or 'when not to use'. Given there is a 'trip' sibling, the description doesn't say to use this for listings and 'trip' for a single trip. The mention of an optional people bridge is the only guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds useful behavioral context by noting that each record includes the window it was measured over, and that these windows differ across records. However, it does not disclose other potentially relevant behaviors such as whether the tool filters by current user, what units are returned, or any data freshness caveats.
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?
The description is highly concise and well-structured. It front-loads the core idea ('The extremes'), then provides a clean list of record types, and finishes with an important nuance about measurement windows. Every word earns its place; no fluff or redundancy.
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?
Given zero parameters and no output schema, the description adequately sets expectations by listing the specific record types and indicating that each has a measurement window. It could go a bit further by clarifying what 'fastest' or 'farthest' refer to, but the level of detail is sufficient for a user to infer the tool's scope.
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?
The tool has zero parameters, so the baseline is 4. The description has no responsibility to explain parameters, and it correctly avoids any parameter-related noise. It does not need to compensate for schema gaps because there are none.
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?
The description clearly enumerates the content of the tool (various extremes like highest point, fastest, farthest from home, compass records, longest trip, most cities in a day, longest flight), making its purpose evident. It lacks an explicit verb like 'get' or 'list,' but the itemization effectively communicates what the tool provides and distinguishes it from sibling tools that focus on individual data points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many siblings (e.g., top_places, trips, travel_stats). It does not mention alternatives or exclusion criteria. Usage context is only implied by the fact that it aggregates extremes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the three behavioral modes based on parameters and the dependency on the people bridge. However, it does not describe the return format, error conditions, or what happens if both parameters are passed, which are meaningful gaps.
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?
The description is three sentences, front-loaded with the core concept, and each sentence provides distinct information. It is compact and free of fluff.
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?
The tool is simple with 2 optional parameters and no output schema. The description explains the parameter-driven behavior and a prerequisite, making it reasonably complete for this complexity. However, the lack of output format or error handling prevents a higher score.
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 baseline is 3. The description adds value by explaining the semantic meaning of each parameter combination: 'person' for trips, 'trip' for people, neither for all pairings. It also notes that person can be a partial name and trip is a slug, which aligns with the schema.
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?
The description clearly explains that this tool links trips and a people graph bidirectionally, with examples for each parameter combination. It distinguishes itself from sibling tools by focusing on the people graph rather than just location/trip data. However, it lacks a strong verb like 'list' or 'get', making the action slightly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the parameter examples: pass 'person' for trips shared, 'trip' for people tagged, neither for all pairings. It also notes a prerequisite (the optional people bridge). However, it does not explicitly mention when to prefer this tool over siblings or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden of disclosure. It explains the output structure (separate trips, time spent, distinct days, cities) and the country filter, but does not mention default behavior with no parameters, ordering, or edge cases like ambiguous country names. It provides a functional overview but lacks depth.
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?
The description is concise (two sentences), front-loaded with the purpose, and every sentence adds value. The example with the country filter is useful without being verbose.
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?
Given no output schema, the description covers the key return elements (trips, time, days, cities) and the filtering behavior. It does not state the default when no country is provided or how the results are structured, but it is sufficiently complete for an agent to select and invoke the tool for common use cases.
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?
The input schema already provides 100% coverage of parameter meanings. The description adds a brief example for the country parameter, but since and until/period semantics are already well-documented in the schema, so minimal added value.
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 clearly states the tool's function: it provides country-level travel statistics over a period, including trips, time spent, distinct days, and cities. It also distinguishes itself from siblings like cities_visited and trips by focusing on countries as the aggregation unit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for country-focused travel queries and gives a concrete example of filtering by country ('how many times have I been to Japan'). However, it does not explicitly contrast with alternatives such as cities_visited or trips, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output metrics but not behavioral details such as how 'home' is defined, whether the tool is read-only, or any edge-case handling. The read-only nature is implied by the stats context but not stated.
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?
The description is a single, front-loaded sentence that efficiently enumerates the key output categories. Every word adds value, and the structure makes it easy to scan.
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?
Given the absence of an output schema, the description does a good job listing the main output dimensions (kilometres by mode, flights, days away, countries/cities). It is reasonably complete for a simple stats tool, though it could clarify the definition of 'home' or the read-only nature.
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?
The schema provides full descriptions for all three parameters (since, until, period), so the description adds little beyond reinforcing that the tool looks at 'a period'. It does not clarify parameter interactions beyond what the schema already states.
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 clearly defines what the tool does: it reports movement stats over a period, listing specific metrics (km by mode, flights, days away from home vs at home, countries/cities). This distinguishes it from sibling tools like cities_visited or trips, which provide detailed lists rather than aggregate statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (getting travel summary stats) but gives no explicit guidance on when to prefer this tool over alternatives or when not to use it. It does not mention that detailed trip-level info is available in 'trips' or that cities_visited/countries_visited provide raw lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the return content (time in each city, number of separate visits, specific days), which is meaningful beyond the input schema. It does not mention read-only semantics explicitly, but no side effects are suggested.
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?
The description is a single, information-dense sentence with a practical example, no redundancy.
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 read-only query tool with four optional parameters and no output schema, the description covers the output fields and a concrete use case. It omits sort order and timezone handling, but the schema fills in parameter semantics.
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 baseline is 3. The description's 'over a period' loosely maps to since/until/period, but it adds no parameter-specific detail beyond what the schema already provides.
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?
The description clearly identifies the resource as cities visited within a time range and specifies the output dimensions (time spent, visit counts, days). The example 'which cities did I go to last spring' distinguishes it from sibling tools like countries_visited, though it lacks an explicit imperative verb.
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?
The description explicitly provides a concrete use case ('Use for...'), giving clear context for when to select this tool. It does not name sibling alternatives or state exclusions, but the example is sufficient to signal appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden. It discloses the ordering (most time first) and output fields, which is useful. However, it does not mention data source, potential inaccuracies, or that this is a read-only aggregation, leaving some gaps for a tool with no annotation support.
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?
The description is two sentences, front-loaded with the core function and output, and each sentence contributes. It avoids redundancy and is well-structured.
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?
With no output schema, the description covers return values (address, city, source label, stops, hours) and ordering. It omits caveats like pagination or data source limitations, but for a listing tool with well-specified schema, this is nearly complete.
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 description coverage is 100%, so the baseline is 3. The description adds little parameter-specific meaning beyond mentioning 'address' in the output, which indirectly relates to the search filter. It does not explain parameter interactions or defaults beyond what the schema already provides.
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 clearly states the tool returns places ordered by time spent, with specific fields (address, city, source label, stops, hours). It also gives explicit use cases ('where do I actually spend my time' or to find an address), which distinguishes it from sibling tools like trips or stays.
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 use contexts: 'where do I actually spend my time' and 'find an address'. It does not name alternative tools or explicitly state when not to use it, but the guidance is sufficient to direct an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals a key trait: home is a timeline, not a point, meaning it returns a sequence over time rather than a single address. This prevents misuse, though it does not specify the exact output format or whether it includes current residences.
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 core purpose. Both sentences add distinct value: the first states what it returns, the second clarifies the conceptual model and usage. 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 no-parameter tool with no output schema, the description is mostly complete. It explains the fundamental difference from a point-in-time location and instructs on usage. It could be more explicit about return values (e.g., list of addresses with dates), but the phrase 'where they have lived and when' sufficiently implies this.
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?
The tool has zero parameters, giving a baseline of 4. The description adds context by explaining why no address parameter is needed: because home is a timeline covering all residences, so the tool should be consulted rather than assuming one address. This reinforces the parameter-less design.
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?
The description clearly states the tool provides a history of residences ('Where they have lived and when'), and explicitly distinguishes it from a single-address assumption. However, it lacks a specific verb like 'list' or 'get', and the purpose is expressed as a noun phrase rather than an actionable command.
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?
The second sentence gives direct usage guidance: 'anything home-relative has to read this rather than assume one address.' This tells the agent when to use this tool and warns against assuming a single point. It does not explicitly name alternative sibling tools, but the contrast with 'point' implies current_location or similar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the read-only nature ('Read-only SELECT'), which is critical safety information. However, it does not describe other behavioral traits such as query result limits (beyond schema), performance expectations, or error handling, leaving some uncertainty for a raw SQL tool.
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?
The description opens with a concise, front-loaded purpose statement and then systematically organizes the database objects into Tables, Views, and a conditional 'people bridge' section. It is long due to the schema listing, but every piece is relevant for a raw SQL tool, so the length is justified.
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?
Given the tool's complexity (arbitrary SQL), providing the full schema is essential and mostly complete. It also notes the optional people bridge installation. However, it lacks an example query, any note about query complexity limitations, or details on how results are returned, which would make it fully complete.
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?
Although schema descriptions cover both parameters, the tool description adds substantial context for the 'query' parameter by enumerating all available tables and views with their columns. This transforms a generic 'SELECT statement' into something actionable. The 'limit' parameter is not elaborated further, so the score reflects the high value added for the primary parameter.
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 starts with 'Read-only SELECT', a specific verb and resource that clearly defines the tool's action. It also distinguishes itself from siblings with 'for questions the other tools do not shape', signaling it's the fallback for raw SQL queries. The detailed list of tables and views further specifies its domain.
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?
The phrase 'for questions the other tools do not shape' gives clear context for when to use this tool instead of dedicated tools. However, it does not name specific sibling tools or state explicit exclusions (e.g., 'use trips for travel overviews'), so the guidance is good but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the chronological ordering and the output fields. However, it doesn't mention potential grouping behavior when the 'by' parameter is used, nor any default period or timezone considerations.
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 sentences, front-loaded with the main purpose and followed by a concrete use case. Zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description explains the basic output structure but omits how parameters like 'by', 'period', and filters interact. The ambiguity between 'every stop' and the 'by' granularity leaves some gaps.
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?
All 7 parameters have schema descriptions (100% coverage), so the schema does the heavy lifting. The description adds no parameter-specific information beyond the general 'over a period' 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 uses a specific verb ('list'), names the resource ('stays'), and specifies the scope ('over a period') and content ('every stop with start, end and duration, the trip it belongs to, and the place'). It also differentiates from siblings by explicitly mentioning reconstruction of a day/week/trip, which sibling tools like 'day' or 'trip' likely serve.
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 provides clear context: 'Use it to reconstruct a day, a week or a trip in order.' This tells when to use it, but it does not mention when not to use it or alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the data returned and the identification mechanism, but does not disclose behavior in edge cases (e.g., missing parameters, non-existent slug, multiple matches). It is not misleading, but could be more transparent about failure modes or read-only nature.
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 key output ('One trip in full') and a clear list of contained data. No redundant content; every phrase adds value.
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?
Given the absence of an output schema, the description effectively enumerates all major components (day-by-day country/city, stays, journeys with mode/distance, people, note). It also explains how to identify the trip. It could be slightly more explicit about the requirement to provide at least one identifier, but overall it is complete for a retrieval tool.
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?
The schema already provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds beyond the schema by clarifying that the parameters are alternative identifiers ('by slug, by name, or by a date inside it') and elaborates on the date parameter ('any date inside the trip'). This enhances parameter semantics.
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 clearly states what the tool does: it retrieves a complete trip with all its details (day-by-day itinerary, stays, journeys, people, note). It uses a specific resource ('One trip') and distinguishes it from siblings like 'trips' (plural list) and 'day' (single day).
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?
The description gives clear identification methods (slug, name, or date) and implies when to use this tool (when you need the full trip details). However, it does not explicitly exclude alternatives like 'day' or 'stays', so it lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the tool's output content and ordering (stays in order, journeys between them, trip it belongs to), giving agents a detailed expectation of results. It doesn't discuss side effects, but as a read-only tool this is acceptable.
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?
The description is two sentences long with no fluff. The first sentence packs a dense but readable specification of what is returned; the second provides a concrete usage example. Every word earns its place.
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?
Given one optional parameter and no output schema, the description is remarkably complete. It outlines the full response content, ordering, and association with trips, making the tool's behavior clear enough for an agent to invoke correctly without additional docs.
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?
The input schema already fully documents the sole parameter 'date' with format and default (100% coverage). The description adds no new parameter semantics beyond referencing a date example, so the baseline of 3 applies.
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 clearly states the tool provides a comprehensive view of a single date: wake-up location, stays in order, journeys with mode and distance, trip association, and distance from home. It distinguishes itself from siblings like 'stays' or 'trip' by covering the full day's narrative.
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?
The description explicitly advises using it for 'what did I do on the 8th', giving a clear use case. It doesn't mention alternatives or exclusions, but the context is sufficiently clear to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden. It discloses that the tool returns coverage metadata (table-by-table, spans, gaps) rather than location data, and warns about the interpretive pitfall. This provides meaningful behavioral context beyond simply stating 'shows coverage.'
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?
The description is two sentences long and front-loaded: the first sentence states the tool's output directly, and the second provides a concise usage warning. Every word earns its place; there is no filler.
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 zero-parameter tool with no output schema, the description covers purpose, output scope, and usage context. It could optionally include an example of the response structure, but the current content is sufficient for an agent to decide when to use it and what to expect.
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?
The tool has zero parameters, and the schema confirms this with 100% coverage. The description adds context about the output (tables, spans, gaps) but no parameter details are needed. Per the rubric, 0 params yields a baseline of 4, and the description aligns well with that.
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 clearly states what the tool does: it reports what the archive holds, table by table, including the span each source covers and gaps of two weeks or more. It uses a specific resource ('the archive') and distinguishes itself from sibling location-query tools by focusing on data coverage rather than location data itself.
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?
The second sentence explicitly instructs when to use this tool: 'Check this before concluding someone was never somewhere.' It also explains the critical distinction between 'no record' and 'was not there,' which is valuable guidance. While it doesn't name specific alternative tools, the context makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses a rich set of behavioral details: the exact fields returned (including fix age, trip/day, distance from home), which implies potential staleness and contextual richness. It doesn't mention side effects or permissions, but for a read-only location tool this is reasonable.
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?
The description is a single sentence plus a directive. It front-loads the core purpose, lists all relevant outputs, and includes a usage note. Every word earns its place; no fluff or repetition.
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?
For a tool with no parameters and no output schema, the description is remarkably complete. It enumerates all the data the agent will receive and provides a clear usage rule. There is no missing information that would prevent correct invocation or interpretation.
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?
The tool has zero parameters, so schema coverage is trivially 100%. No parameter explanation is needed. Baseline for 0 params is 4, and the description adds useful context about what the tool returns without needing to describe inputs.
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 clearly states what the tool does: it returns the user's current location with specific details (address, coordinates, local time, fix age, trip/day, distance from home). It uses a specific resource ('current location') and distinguishes from sibling tools like 'home' or 'trip' by emphasizing the current, real-time nature.
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?
The description provides explicit usage guidance: 'Read this before saying anything about where they are.' This tells the agent when to use the tool (before making any location claims). It does not explicitly name alternatives or exclusions, but the directive is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tars-location-mcp MCP server](https://glama.ai/mcp/servers/michelgrolet/tars-location-mcp/badges/card.svg)](https://glama.ai/mcp/servers/michelgrolet/tars-location-mcp)

Score Badge

Copy to your README.md:

[![tars-location-mcp MCP server](https://glama.ai/mcp/servers/michelgrolet/tars-location-mcp/badges/score.svg)](https://glama.ai/mcp/servers/michelgrolet/tars-location-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/michelgrolet/tars-location-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server