PinMeTo Location MCP

Official

by PinMeTo

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v4.0.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., single vs all vs search, reviews vs ratings vs insights). Some overlap exists between get_google_ratings and get_google_review_insights, and between get_google_reviews and get_google_review_insights, but the descriptions explicitly cross-reference each other to guide selection.
Naming Consistency5/5
All tools follow a consistent pinmeto_get_<platform>_<metric> pattern with lowercase snake_case. The only deviation is search_locations using 'search' instead of 'get', but the pattern remains recognizable and predictable.
Tool Count5/5
12 tools is well-scoped for a location data aggregator covering multiple platforms. Each tool serves a distinct data need without excessive granularity.
Completeness4/5
The server covers location retrieval (single, all, search), Google insights, ratings, reviews, keywords, and review insights, plus Facebook and Apple metrics. Gaps include lack of Facebook reviews and Apple ratings/reviews, and the review insights tool admits it doesn't differentiate certain analysis types, but core data access is solid.
Average 4.6/5 across 12 of 12 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on July 30, 2026
- 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is complemented by detailed behavioral disclosures: a 10-day data lag warning, incomplete current-month data, and specific error handling (RATE_LIMITED, NOT_FOUND, structuredContent.errorCode/retryable). This goes beyond the annotation to inform the agent of important runtime behaviors.
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 is front-loaded with the core purpose, followed by two well-structured bullet sections for data lag and error handling. It is somewhat long but every sentence conveys necessary operational details without 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?
The description covers the main operation, data freshness caveats, and error handling, while the output schema presumably documents return values. Given the moderate complexity and rich annotations/schema, it is adequately complete, though it does not discuss alternative tools or specific 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?
Schema description coverage is 100%, so the schema already documents all four parameters. The description only mentions storeId briefly ('if storeId provided'), adding no additional semantic 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch Google keywords for all locations, or a single location if storeId provided,' specifying the action (Fetch), resource (Google keywords), and scope (all or single location). This distinguishes it from sibling tools such as get_google_insights or get_google_reviews.
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 gives context that the tool can fetch keywords for all locations or a single one via storeId, but it does not explicitly compare with or exclude other tools like insights or reviews. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds detailed error-handling behavior beyond the readOnlyHint annotation: rate-limit handling with retry timing, not-found behavior, and guidance to check structuredContent.errorCode and .retryable. This is valuable behavioral context not available in the annotation or schema.
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 front-loaded with the main purpose, then uses a structured bullet list for error handling. Every sentence earns its place; there is no filler or redundancy. The short, organized format makes it easy to parse.
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 an output schema present, the description does not need to explain return values. It covers the core behavior and error handling comprehensively. However, it does not mention any usage boundaries or specific scenarios beyond the storeId branch, leaving a small gap in contextual completeness for a tool that has many sibling tools.
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%, with all parameters described clearly (from/to as dates, storeId as optional, response_format as enum). The description merely restates the storeId behavior already in the schema, adding no new meaning. Baseline of 3 is appropriate when the schema fully documents parameters.
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 resource ('Facebook ratings') and the action ('Fetch'), with specific scope: all locations or a single location if storeId is provided. This distinguishes it from sibling tools like pinmeto_get_facebook_insights, which target insights rather than ratings.
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 gives context on how to fetch a single location vs all locations via storeId, but it does not explicitly state when to prefer this tool over alternatives like get_google_ratings or get_facebook_insights. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true, the description adds valuable behavioral context: it discloses rate-limit error codes, 404 handling, and the structuredContent error schema. It also explains that comparison mode adds a comparison field with prior, delta, and deltaPercent, which is not visible in annotations or schema. This goes well beyond the annotation baseline.
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, front-loaded with the main purpose, and uses clear bullet sections for comparison options and error handling. Every sentence adds value, and there is no verbosity or redundancy with the schema.
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 an output schema present, the description does not need to detail return values. It adequately covers location scoping, aggregation default, comparison behavior, and error handling. The only gap is the lack of explicit differentiation from the sibling get_facebook_brandpage_insights, which is minor given the strong overall coverage.
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 enhances semantics by explaining compare_with options in detail (MoM, QoQ, YoY) and the resulting delta fields. It also clarifies that storeId limits to a single location. This adds meaning beyond the schema, though not for all six parameters.
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 opens with a specific verb and resource: 'Fetch Facebook metrics for all locations, or a single location if storeId provided.' This clearly distinguishes the tool from Google/Apple insights siblings and conveys both the platform and scope. Although it does not explicitly contrast with get_facebook_brandpage_insights, the 'Facebook metrics' phrasing is still unambiguous.
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 clearly implies usage for Facebook metrics, but it does not provide explicit when-to-use guidance or name alternatives such as get_facebook_brandpage_insights for brand-page-specific metrics. No exclusions or 'instead of' guidance is given, so the agent must infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses substantial behavioral context: a ~10 day data lag warning, comparison field details (prior, delta, deltaPercent), and a complete error-handling section with specific errorCodes and retryable flags. This exceeds what annotations alone provide and gives the agent actionable operational knowledge.
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 well-structured with clear sections: a one-line core purpose, followed by concise subsections for Comparison Options, Data Lag Warning, and Error Handling. Every sentence contributes essential operational knowledge, and the formatting makes it easy to scan. No redundancy or filler.
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 the tool's complexity (6 params, enums, output schema), the description thoroughly covers usage nuances: aggregation choices, comparison semantics, data lag caveats, and error handling. The output schema handles return value structure, so the description focuses on decision-relevant behavior. This is a complete and self-sufficient description for an agent.
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?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining the output effect of compare_with (inclusion of prior, delta, deltaPercent fields) and noting that 'total' aggregation yields 'maximum token reduction'—information not present in the schema. These additions help the agent reason about parameter consequences beyond mere syntax.
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 opens with a specific verb and resource: 'Fetch Google metrics for all locations, or a single location if storeId provided.' This clearly distinguishes the tool from siblings like get_google_ratings or get_google_reviews by scoping it to general Google insights, and the optional storeId parameter explicitly defines the single-location variant.
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 by explaining capabilities (aggregation, period comparisons) and datasets (Google metrics), but it never explicitly names alternatives or states when to use this tool versus a sibling. The behavior around comparison and data lag is context, not selection guidance. This is acceptable 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the readOnlyHint annotation, the description adds valuable error handling details: 404 NOT_FOUND, 401 AUTH_INVALID_CREDENTIALS, and the retryable flag for programmatic handling. This goes well beyond the annotation's safety signal.
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 and front-loaded with the purpose, followed by a structured error-handling list. Every sentence earns its place, with no redundant or vague content.
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 simple single-record read tool, the description is complete: it explains the purpose, error handling, and parameter semantics are covered by the schema. The presence of an output schema means return values need no further explanation, and the error handling adds important context.
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%: both storeId and response_format are described in the schema. The description mentions 'by store ID' but doesn't add meaningful semantic information beyond what the schema already provides, so the baseline of 3 holds.
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 'Get details for a SINGLE location by store ID' with a specific verb, resource, and scope. This distinguishes it from sibling tools like pinmeto_get_locations (plural) and pinmeto_search_locations, and lists the data returned.
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 implies use when you have a specific store ID and says 'SINGLE location', which differentiates from listing or searching. However, it doesn't explicitly name alternatives or exclusion criteria, so it stops short of full 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?
The readOnlyHint annotation already indicates a safe read operation, and the description adds valuable behavioral details beyond that: it mentions the lightweight nature of results, and provides a comprehensive error handling section with specific errorCode and retryable fields. This is more than what annotations convey, though it doesn't cover all possible behaviors like pagination.
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 concisely structured: two sentences for the main purpose and then a structured error handling block. Every sentence provides useful information, with no redundant or filler content. The error handling details are presented in a clear, scannable format.
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?
With a fully described input schema, an output schema, and annotations declaring read-only behavior, the description is sufficiently complete. The error handling section adds additional context, and the guidance about lightweight results and using get_location for full details fills any remaining gaps for a search tool.
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 has 100% description coverage for all three parameters, so the baseline is 3 per the rubric. The description adds no additional parameter semantics beyond what the schema already provides; it mentions search fields ('name, address, store ID, or location descriptor') but the schema already lists these plus more. No extra value added.
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 'Search ALL locations by name, address, store ID, or location descriptor', providing a specific verb and resource with explicit search scope. It distinguishes itself from the sibling tool pinmeto_get_location by noting that the latter should be used for full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Returns lightweight results for quick discovery' and directs users to 'Use pinmeto_get_location with storeId for full details'. This provides a clear alternative and decision point, matching the pattern of the high-scoring calibration example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint: true, the description adds substantial behavioral context: how comparisons affect metrics (comparison fields with prior, delta, deltaPercent), detailed error handling for rate limits and not-found cases, and guidance to check structuredContent.errorCode and retryable. This goes well beyond the annotation.
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 well-structured with clear sections: main purpose first, then comparison options, then error handling. It uses bullet points without excessive length, and every sentence provides distinct value. No redundancy or fluff.
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 the tool's complexity (6 params), the presence of an output schema, and read-only annotation, the description is remarkably complete. It covers error handling, comparison behavior, and aggregation defaults, while leaving return-value details to the schema. This is sufficient for an agent to select and invoke the tool correctly.
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 the baseline is 3. The description adds value by explaining comparison semantics (MoM, QoQ, YoY) and the behavior when comparison is active. It also clarifies the 'total' aggregation's token-reduction benefit. This extra context justifies a 4.
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 opens with a specific verb+resource statement: 'Fetch Apple metrics for all locations, or a single location if storeId provided.' This clearly identifies the tool's function and scope, and the 'Apple' qualifier distinguishes it from sibling Google/Facebook insights tools.
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 clear context for use—fetching Apple metrics with optional storeId, aggregation, and comparison. However, it does not explicitly state when not to use it or name alternatives. The sibling distinction is implied by 'Apple metrics' but not stated as an exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds valuable behavioral disclosures: detailed error handling for 429 and 401, the structuredContent.errorCode and retryable fields, and the behavior of comparison fields (priorValue, delta, deltaPercent). This goes well beyond the annotation and gives the agent concrete expectations for edge cases.
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 well-structured with clear sections for comparison options and error handling. It is concise, front-loaded with the core purpose, and every sentence adds value. No fluff or repetition of schema basics beyond necessary context.
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 the presence of an output schema and readOnly annotation, the description covers all essential aspects: what the tool does, how aggregation works, comparison mechanics, and error handling. It is complete enough for an agent to invoke the tool confidently and interpret the result even before seeing the output schema.
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 input schema already has 100% coverage with descriptions for all five parameters, so the baseline is 3. The description adds important semantic value by explaining what 'compare_with' actually does (MoM/QoQ vs YoY), including the effect on output metrics (flat comparison fields). It also clarifies response_format token-efficiency, enriching the schema definitions.
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 opens with a specific verb and resource: 'Fetch Facebook metrics for all brand pages.' It clearly differentiates from sibling tools by specifying 'all brand pages' (as opposed to perhaps a single page). The scope is unambiguous and the mention of aggregation and comparison further clarifies the tool's purpose.
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 clear usage context by explaining supported aggregation types and comparison periods, but it does not explicitly mention when to use this tool over its sibling tools (e.g., pinmeto_get_facebook_insights). It could improve by stating 'for a single brand page, use pinmeto_get_facebook_insights' or similar. Still, the context is clear enough that an agent can infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses in-memory cache behavior with a 5-minute TTL, force refresh capability, partial result handling on API errors, stale cache fallback, and errorCode/retryable fields. This provides substantial behavioral context that the annotation alone does not convey.
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 well-structured with clear sections for purpose, examples, and error handling. It front-loads the core purpose and keeps each section appropriately concise without redundant filler. The length is justified by the tool's complexity and the valuable usage examples.
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 list tool with 9 parameters and an output schema, the description covers pagination, filtering, caching, and error behavior comprehensively. It mentions 'incomplete field' for partial results and 'structuredContent' for error details, and because an output schema exists, it does not need to enumerate return fields. This is complete for the tool's complexity.
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 documents all 9 parameters with 100% coverage, so the baseline is 3. The description adds value through concrete examples like 'Filter by city: { city: "Stockholm", limit: 20 }' and 'Force cache refresh: { forceRefresh: true }', which illustrate parameter combinations and real usage patterns beyond the schema descriptions.
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 opens with 'Get ALL locations with pagination and filtering,' which clearly states the action, resource, and scope. The word 'ALL' distinguishes it from the sibling tool 'pinmeto_get_location' and emphasizes its list-oriented 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 clear examples of pagination, filtering by city, and open/closed status, giving practical usage context. However, it does not explicitly contrast with 'pinmeto_search_locations' or state when to prefer one over the other, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description carries the burden of behavioral disclosure. It reveals critical behaviors: server-side aggregation, token efficiency, caching with forceRefresh, warning flags for undifferentiated types, and the multi-tier large-dataset confirmation flow. This adds substantial context beyond the read-only hint.
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 is longer than average but justified by the tool's complexity. It is well-structured with headers and bullets, and each section adds actionable detail. Slight redundancy (e.g., theme extraction limitation appears twice) prevents a perfect score, but it's far from bloated.
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 the tool's 11 parameters, large-dataset handling, and multiple analysis modes, the description covers all critical usage scenarios: data volume behavior, sampling, caching, and output nature. An output schema exists, so return-value details are not needed. No gaps are evident.
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 valuable nuance: analysisType values like 'issues' and 'trends' return the same payload as summary, themes is ignored, skipConfirmation is used after a warning, and sampling strategies have specific meanings. This enriches the plain schema enum and boolean definitions.
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 opens with a clear verb+resource statement: 'Summarize Google reviews into rating and sentiment statistics.' It goes on to list distinct analysis types (summary, comparison, issues, etc.) and contrasts with sibling tools like pinmeto_get_google_reviews and pinmeto_get_google_ratings, making the tool's unique role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'When NOT to use this tool' section naming three sibling tools and the exact conditions under which each should be preferred. It also explains when to use different analysis types and large-dataset options, giving clear selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true, the description adds substantial behavioral context: aggregate-only results, 5-minute caching shared with the reviews tool, forceRefresh bypass, ~10 day data lag, and specific error codes/retryable flags. This goes far beyond the annotation.
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 well-organized into short labeled sections (caching, data lag, error handling), front-loads the core purpose, and every sentence adds useful information without fluff.
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 the tool has a full output schema and read-only annotation, the description covers all needed aspects: purpose, alternative, caching, data freshness, and error handling, making it fully complete for agent selection and invocation.
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 the baseline is 3. The description adds value by explaining storeId's role in fetching a single location and forceRefresh's cache-bypass behavior, which complements the schema without repeating it.
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 ('Fetch'), identifies the resource ('Google rating statistics'), and clearly defines scope ('for all locations, or a single location'). It also distinguishes itself from the sibling tool pinmeto_get_google_reviews by noting it returns aggregate statistics only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly points to the alternative tool for individual review text and sentiment analysis ('use pinmeto_get_google_reviews'), and provides practical usage context through caching, data-lag warnings, and error-handling notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations only providing readOnlyHint=true, the description discloses significant behavioral traits: caching with a 5-minute TTL shared with the ratings tool, client-side filter application, a ~10 day Google data lag warning, pagination signaling via hasMore, and structured error codes with retryable flags. These enrich the agent's understanding of side effects, latency, and error semantics far beyond the annotation baseline.
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 extensively detailed yet efficiently structured with clear sections for purpose, pagination, filtering, caching, data lag, and error handling. Every sentence adds value, no filler content exists, and the most important purpose statement is front-loaded. Despite its length, it remains highly scannable and appropriately sized for the tool's complexity.
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 the tool's complexity (10 parameters, output schema, caching, rate limits, data lag), the description covers all critical operational aspects: differentiating use, pagination mechanics, filtering semantics, cache behavior, data freshness warnings, and error handling. The existence of an output schema means it doesn't need to detail return fields, and nothing essential is missing for an agent to correctly invoke and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the description adds meaning beyond the schema. It explains pagination semantics ('Check hasMore in response'), clarifies that filters are applied client-side on cached data, and details the forceRefresh behavior and error code structure. This contextual information is absent from the raw schema properties and helps the agent use the parameters correctly.
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 opens with a specific verb and resource: 'Fetch individual Google reviews with pagination and filtering for sentiment analysis.' It clearly distinguishes itself from the sibling tool 'pinmeto_get_google_ratings' by directing users there for aggregate statistics. This unambiguous purpose, combined with explicit sibling differentiation, warrants a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool versus an alternative: 'For aggregate statistics (averageRating, totalReviews), use pinmeto_get_google_ratings instead.' It also provides detailed guidance on pagination, filtering, caching, and error handling, giving the agent clear decision rules. This goes beyond basic context to include exclusions and alternatives.
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:

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

Score Badge

Copy to your README.md:

[![pinmeto-location-mcp MCP server](https://glama.ai/mcp/servers/PinMeTo/pinmeto-location-mcp/badges/score.svg)](https://glama.ai/mcp/servers/PinMeTo/pinmeto-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/PinMeTo/pinmeto-location-mcp'

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