Skip to main content
Glama
Sign In
OurFamilyWizard MCP

OurFamilyWizard MCP

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Search AllTrails

alltrails_search
Read-onlyIdempotent

Search AllTrails by name for trails, POIs, areas, or cities. Filter results by type and select compact or full views.

Instructions

Search AllTrails by name. A free-text query goes to the suggestions endpoint the alltrails.com search box itself uses — relevance is good and the limit is honored. Results may mix record types (trail, poi, area, city, …); pass types=["trail"] to narrow. lat/lng are accepted for backward compatibility but verified ignored by the API (2026-07-02) — results carry an implicit account/IP geo bias instead. Without a query this falls back to the legacy explore search, which returns trails anchored to the signed-in account's location. Results come back as slim per-result summaries, capped at limit client-side, by default; pass view:"full" for AllTrails' whole records.

Input Schema

NameRequiredDescriptionDefault
latNoDeprecated — the API ignores it (verified 2026-07-02)
lngNoDeprecated — the API ignores it (verified 2026-07-02)
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact returns slim per-result summaries capped at limit; "full" returns AllTrails' whole records.
limitNoMax results to return (default 20)
queryNoFree-text search, e.g. "angels landing" or "waterfall trails"
typesNoRecord types to return (default: all). e.g. ["trail"] for trails only. Only applied when query is provided; silently ignored on the no-query legacy browse fallback.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed2 schema fields changedv2.3.1
    • removedInput schema / properties / compact
      Removed value: -{
-  "description": "Return slim per-result summaries capped at limit instead of the full records (default false)",
-  "type": "boolean"
-}
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact returns slim per-result summaries capped at limit; \"full\" returns AllTrails' whole records.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  3. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/open-world/idempotent safety, yet the description adds material behavior beyond them: lat/lng are verified ignored by the API with a date-stamped verification, results carry an implicit account/IP geo bias instead, the no-query path falls back to legacy explore anchored to the signed-in account's location, and results are capped client-side. These are exactly the non-obvious traits an agent needs.

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?

Information-dense and front-loaded with the core search behavior before the caveats, and every clause carries real content (endpoint identity, type narrowing, deprecation, fallback, view modes). It is a single long block with em-dash-heavy nesting, which costs some scannability but no sentence is 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?

With no output schema present, the description steps up and describes return shape (slim per-result summaries capped at limit, or full AllTrails records under view:"full"). Combined with the fallback and geo-bias disclosures, an agent has everything needed to call this correctly given 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?

Schema description coverage is 100%, so the baseline is 3, but the description goes further by explaining that lat/lng are backward-compatibility only and effectively no-ops, and that the account/IP geo bias substitutes for them. The types-only-applied-with-query rule is largely mirrored in the schema, so the net gain over structured data is moderate rather than decisive.

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?

Opens with a specific verb+resource ("Search AllTrails by name") and immediately names the mechanism (the suggestions endpoint the site's own search box uses). This is clearly distinguishable from siblings like alltrails_get_trail, alltrails_resolve_location, or alltrails_list_user_lists, which are retrieval/filter tools rather than free-text search.

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?

Gives clear operative guidance: pass types=["trail"] to narrow mixed record types, and pass view:"full" for whole records. It also explains the no-query fallback behavior, which tells the agent when the tool behaves differently. It does not, however, route the agent to a sibling alternative (e.g. resolve_location or get_trail), so the comparative guidance is incomplete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools