Skip to main content
Glama
PinMeTo

PinMeTo Location MCP

Official
by PinMeTo

Google search keywords

pinmeto_get_google_keywords
Read-only

Fetch Google search keywords for all locations or a single store within a selected month range. Choose JSON or Markdown output, with warnings for incomplete Google data.

Instructions

Fetch Google keywords for all locations, or a single location if storeId provided.

Data Lag Warning:

  • Google data has ~10 day lag. Current month data may be incomplete.

  • Check structuredContent.warning and warningCode for data completeness.

Error Handling:

  • Rate limit (429): errorCode="RATE_LIMITED", message includes retry timing

  • Not found (404): errorCode="NOT_FOUND" if storeId doesn't exist

  • All errors: check structuredContent.errorCode and .retryable for programmatic handling

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesEnd month (YYYY-MM)
fromYesStart month (YYYY-MM)
storeIdNoOptional store ID to fetch a single location
response_formatNoResponse format: "json" (default, token-efficient) or "markdown" (human-readable with tables)json

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoArray of keywords with impression data (absent on error)
errorNoError message if the request failed
errorCodeNoError code for programmatic handling
retryableNoWhether the operation can be retried

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv4.3.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / properties / data / items / additionalProperties
      Previous value: -trueNew value: +{}
  2. First observedv4.0.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses important behavioral details: the ~10 day data lag, possible incomplete current-month data, structuredContent.warning/warningCode fields, rate-limit behavior with errorCode RATE_LIMITED, not-found behavior with NOT_FOUND, and the retryable flag. This gives an agent a strong understanding of edge cases and response characteristics.

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 core operation, then uses compact bulleted sections for data lag and error handling. Every sentence adds useful information, and the structure makes the warnings and error details easy to scan. There is no filler or repetition of schema 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?

The description is complete for a tool with an output schema and readOnly annotation. It covers data freshness, programmatic error handling, and the storeId filtering behavior. The output schema already handles return-value details, so the description does not need to repeat them. An agent has enough context to invoke the tool correctly and interpret failure/warning conditions.

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, so the baseline is 3. The description does not add substantial parameter-level detail beyond the schema: it restates the storeId single-location behavior, which the schema already documents. There is no extra meaning about from/to or response_format, so no score above baseline is warranted.

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 keywords for all locations, or a single location if storeId provided.' This clearly distinguishes the tool from siblings like google_insights, google_ratings, and google_reviews, and also clarifies the scope difference between all locations and a single filtered location.

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 context for when to use the tool: it fetches keywords for all locations or a single location when storeId is supplied. It also includes a data lag warning that implies the tool is best for historical/complete data. It does not explicitly name sibling alternatives or state when not to use this tool, so it stops 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.