Google_maps
Server Details
Google Maps MCP Pack — geocoding, places, directions, distance matrix, elevation.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-google_maps
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.5/5 across 11 of 12 tools scored. Lowest: 2.7/5.
The maps_* tools are clearly distinct and well-named, but ask_pipeworx overlaps significantly with them as it claims to pick the right tool and fill arguments, making it ambiguous whether agents should use maps_* tools directly or rely on ask_pipeworx. Similarly, discover_tools is redundant given the small set of tools.
Tool names are inconsistent: maps_* tools use snake_case with a clear prefix, but ask_pipeworx, discover_tools, forget, recall, and remember break this pattern. Some verbs are imperative (forget, recall, remember) while others are descriptive (ask_pipeworx, discover_tools).
With 12 tools, the count is reasonable for a mapping service, but the inclusion of 5 non-mapping tools (memory and pipeworx-related) dilutes the focus. A few tools like discover_tools and ask_pipeworx seem unnecessary given the small set.
The mapping tools cover geocoding, directions, distance matrix, elevation, place search, and details, which is fairly complete. However, missing are tools for place photos, nearby search without explicit location, or traffic info. The memory tools add generic persistence but are out of domain.
Available Tools
12 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states it picks the right tool and fills arguments, explaining its orchestration behavior. Does not disclose rate limits or failure modes, but for a question-answering tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first defines purpose, second explains behavior, third gives examples. Extremely efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), description is complete enough. It explains what the tool does and how to use it. Could mention return format or fallback behavior, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with a single parameter 'question' described as 'Your question or request in natural language'. Description adds value by providing examples and clarifying that it accepts plain English, which the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a natural language query tool that routes to the best data source. Provides specific examples like trade deficit, adverse events, and 10-K filings, distinguishing it from sibling tools that have explicit names (e.g., maps_*) or memory functions (remember/recall).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'no need to browse tools or learn schemas', guiding the agent to use this as a universal query interface. Lacks explicit exclusions or when-not-to-use, but the examples and wording imply it covers many domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It states that results are 'the most relevant tools' and includes a default limit, but does not clarify whether the search is semantic or keyword-based, or how relevance is determined. Some behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a clear purpose: first sentence states action, second describes output, third provides usage guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (tools with names and descriptions). For a search tool with simple parameters, this is complete enough to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter semantics beyond what the schema provides (query as natural language, limit with default and max). Does not explain the impact of the query on search behavior or how to craft effective queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches a tool catalog by description and returns relevant tools with names and descriptions. The verb 'search' and resource 'tool catalog' are specific, and the description differentiates it from siblings by emphasizing discovery and calling it first when many tools are available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this first when 500+ tools are available and needing to find the right ones. This provides clear when-to-use guidance and implies alternatives (other tools) are to be found after this step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetBInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. The description says 'Delete', which implies destructive action, but no details on side effects (e.g., irreversible, requires confirmation, cascading effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear sentence, no wasted words. Front-loaded with action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (1 param, no output schema), the description is adequate but lacks behavioral details about deletion (e.g., confirmation, irreversible, error handling).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'key' is described in the schema, and the description adds context that it refers to a stored memory. Schema coverage is 100%, so baseline is 3; the description adds clarity on the resource type, warranting a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (Delete) and the resource (stored memory) by key. It clearly distinguishes from sibling tools like 'remember' (store) and 'recall' (retrieve), though 'ask_pipeworx' is unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives like 'recall' or 'forget' for memory management. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
maps_directionsCInspect
Get turn-by-turn directions between locations. Returns route, distance, duration, and waypoints. Specify mode: driving, walking, transit, or biking.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Travel mode: driving, walking, bicycling, transit (default: driving) | |
| origin | Yes | Starting point (address or "lat,lng") | |
| _apiKey | Yes | Google Maps API key | |
| destination | Yes | End point (address or "lat,lng") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It does not disclose any behavioral traits such as API key requirements (though _apiKey is in schema), rate limits, or whether the response includes routes, steps, or just a summary. The description is too brief.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it could be slightly more informative without becoming verbose. It is front-loaded but lacks structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, no output schema, no annotations), the description is incomplete. It doesn't cover return format, possible errors, or prerequisites like API key. The tool's purpose is clear but depth is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description adds no additional meaning beyond the schema. It doesn't explain how origin/destination formats affect results or what 'driving' vs 'transit' implies. The parameter 'mode' has enum values but no enum constraint in schema, yet the description doesn't clarify allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and resource ('directions between two locations'), which clearly indicates the tool's function. However, it does not differentiate from sibling tools like 'maps_distance_matrix' that also provide route-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs. alternatives like maps_distance_matrix or maps_geocode. The agent must infer usage from context, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
maps_distance_matrixCInspect
Calculate travel distance and time between multiple location pairs. Returns matrix with distances and durations for specified mode: driving, walking, transit, or biking.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Travel mode: driving, walking, bicycling, transit | |
| _apiKey | Yes | Google Maps API key | |
| origins | Yes | Pipe-separated origins (e.g., "New York|Boston") | |
| destinations | Yes | Pipe-separated destinations (e.g., "Philadelphia|Washington DC") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not mention API key requirements (though schema shows _apiKey), rate limits, or data format. The description is too brief for a tool that requires an API key and likely has usage restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, it could be slightly expanded to include key behavioral info without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain how results are returned (e.g., matrix format), which would be crucial for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it merely states the purpose. No extra context for parameters like mode or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides travel distance and time for multiple origins and destinations, which is specific. However, it does not differentiate itself from sibling tool 'maps_directions', which might provide similar data for a single route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'maps_directions'. The description does not mention use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
maps_elevationBInspect
Get elevation in meters for coordinates. Returns elevation and location data. Use to check altitude or terrain height.
| Name | Required | Description | Default |
|---|---|---|---|
| _apiKey | Yes | Google Maps API key | |
| locations | Yes | Pipe-separated "lat,lng" pairs (e.g., "39.7391,-104.9847|36.4555,-116.8666") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It does not disclose any behavioral traits such as rate limits, authentication needs beyond the API key, or what happens if invalid locations are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the key action. No wasted words, but could benefit from a bit more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and the description is minimal. For a tool with two parameters, it lacks information about return values, error handling, or usage context, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds minimal extra meaning beyond the schema. However, the description provides a clear purpose that contextualizes the parameters, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets elevation data for locations, which is specific and distinguishable from sibling tools like maps_directions or maps_geocode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or when not to use it. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
maps_geocodeBInspect
Convert an address to coordinates. Returns latitude, longitude, and formatted address. Use when you need to locate a place on a map.
| Name | Required | Description | Default |
|---|---|---|---|
| _apiKey | Yes | Google Maps API key | |
| address | Yes | Address to geocode (e.g., "1600 Amphitheatre Parkway, Mountain View, CA") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It indicates a read-like operation (geocoding) but does not disclose behavioral traits such as whether it is read-only, any rate limits, or output format. The description is accurate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the tool's purpose. It is front-loaded and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is minimally adequate but does not clarify return values, coordinate format, or error conditions. Slightly below complete for a production tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for both parameters. The description does not add extra meaning beyond the schema; it simply repeats the function. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to geocode an address to coordinates. It uses a specific verb ('geocode') and resource ('address'), and distinguishes it from sibling tools like reverse geocoding or directions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for converting addresses to coordinates, but does not provide explicit guidance on when to use this tool versus alternatives like maps_reverse_geocode or when not to use it. No context about limitations or prerequisites beyond the required API key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
maps_place_detailsBInspect
Get full details for a place: address, phone, hours, website, and user reviews. Use with a place ID from search results.
| Name | Required | Description | Default |
|---|---|---|---|
| _apiKey | Yes | Google Maps API key | |
| place_id | Yes | Google Place ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must carry the burden. It describes the tool as retrieving details, implying a read-only operation with no side effects. However, it does not disclose any rate limits, quota usage, or required authentication beyond the API key parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, and front-loaded with key information. No wasted words, though the list of fields could be slightly restructured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 simple parameters and no output schema, the description adequately covers the tool's purpose. However, it lacks details on return format, error cases, or any behavioral traits (e.g., what happens if place_id is invalid).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters described clearly in the schema. The description adds no additional semantics beyond what the schema provides (place_id and _apiKey). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed info about a place'), listing specific data fields (address, phone, hours, reviews, rating). It distinguishes itself from siblings like maps_place_search (which lists places) and maps_directions, but could be more explicit about the uniqueness of this tool versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like maps_place_search or maps_reverse_geocode. The description does not mention prerequisites (e.g., obtaining a place_id) or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
maps_place_searchAInspect
Find nearby places by type (e.g., restaurants, hotels, parks). Returns names, addresses, ratings, and distances within a radius (in meters).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., "pizza near Times Square") | |
| radius | No | Search radius in meters (max 50000, default 5000) | |
| _apiKey | Yes | Google Maps API key | |
| location | No | Center point as "lat,lng" (optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full burden. It describes the tool as a search for places, implying read-only behavior. However, it does not disclose any behavioral traits like rate limits, pagination, or result format. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the core purpose. It is front-loaded and concise. Could be improved by adding a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters with full schema coverage and no output schema, the description adequately explains the tool's purpose. However, it lacks guidance on the optional location parameter and does not mention return value shape. For a search tool, agents might benefit from knowing whether results are paginated or how many are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying the purpose of the search (places like restaurants, hotels) and the context of 'nearby a location', which complements the schema fields. However, it does not elaborate on parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search for') and resource ('places nearby a location'), and gives examples of categories (restaurants, hotels). However, it does not distinguish it from sibling tools like maps_place_details or maps_geocode, which could be confused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding places near a location but does not explicitly state when to use this tool versus alternatives like maps_place_details for more info on a specific place, or maps_geocode for converting addresses. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
maps_reverse_geocodeCInspect
Convert coordinates to a street address. Returns formatted address, city, state, and country. Use to identify what's at a specific location.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude | |
| lng | Yes | Longitude | |
| _apiKey | Yes | Google Maps API key |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the basic purpose without disclosing behavioral traits like rate limits, accuracy, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded with purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description is too minimal. Should clarify expected coordinate format (e.g., decimal degrees) and address output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with brief descriptions for lat, lng, and _apiKey. Description adds no additional semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Reverse geocode coordinates to an address' with specific verb+resource, distinguishing from sibling tools like maps_geocode (forward geocoding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives (e.g., maps_geocode for address-to-coordinates). Does not mention required API key or coordinate format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the two modes of operation (by key vs. list all) and the persistence context (session and previous sessions). No hidden behaviors are mentioned, but the description is sufficiently transparent for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. No unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, no output schema, no nested objects), the description is complete. It explains both usage modes and the persistence context. A perfect score would require explicit mention of return format or error handling, but for a minimal tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'key' has a description). The description adds value by clarifying that omitting the key lists all memories, which is not in the schema. This compensates well beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a memory by key or lists all memories when key is omitted. The verb 'retrieve' and resource 'memory' are specific, and the description distinguishes from sibling 'remember' which stores memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to omit the key (to list all memories) and mentions the context (saved earlier in the session or previous sessions). However, no explicit alternatives or when-not-to-use guidance is given, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It explains that memory persists for authenticated users vs. 24 hours for anonymous sessions, but does not disclose other behavioral traits such as whether existing keys are overwritten or if there are limits on storage size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core functionality, the second provides usage guidance and persistence details. Every sentence adds value, and there is no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple key-value structure, no output schema, and no annotations, the description adequately covers the tool's purpose and usage context. It is missing any mention of overwrite behavior or limits, but overall is sufficiently complete for a straightforward memory tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds context by providing example keys like 'subject_property' and 'target_ticker', but does not add meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores a key-value pair in session memory. It distinguishes itself from sibling tools like 'forget' and 'recall' by specifying the action of storing, which is complementary to forgetting and recalling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: saving intermediate findings, user preferences, or context across tool calls. It also notes memory persistence differences between authenticated and anonymous sessions, guiding when the stored data will be available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!