Skip to main content
Glama
magiclane

Magic Lane MCP Docs Server

Official
by magiclane

Find a topic across all Magic Lane SDKs

find_across_sdks
Read-onlyIdempotent

Finds matching documentation for one topic across every Maps SDK and Cloud REST API side by side, enabling cross-platform comparisons.

Instructions

Given one topic (e.g. "add markers", "calculate route", "offline maps"), return the best-matching documentation page(s) for EVERY source side by side — developer guides, the Maps SDKs for Flutter, Android, iOS, C++, TypeScript, and the Cloud REST APIs. Ideal for cross-platform comparisons ("how do I do X on iOS vs Android"; platform names in the query are ignored unless they are part of a feature name, such as "Android Auto", or of a page's title, such as "integrate the sdk", or name the product itself, such as "REST API" — a query that is the title of one of the Cloud REST APIs, such as "geofences api", is answered by that API alone; a query about the platforms themselves, such as "flutter vs android", is answered by each named platform's own overview page). A source reports "(no match)" unless a page matches at least half of the topic words (half in its own title or description, not only in its section) and is about the most specific one: it is in the page's title or section, or in its description or path with every other word too (every word when even that one is common, such as "map"). A topic of one or two words must match in full, and a single one must head the page — unless the title holds the query's other word ("Update Content" for "update maps"), or no page is headed with the word the page lacks there — no page of its source for a word its index entry lacks, no page at all for a single word (never a word next to "API"): then a page whose own text (llms-full.txt) names the missing word at least twice answers, marked as covering part of the topic ("landmark store"; the Cloud's Territory for "generate territories"), and a page whose description names the single word as written (not "key" for "token") in its first sentence and its first two thirds answers when its text names it again ("waypoints"); a page may always lack an action word ("upgrade to 3.1.4") or the words of setting up ("set up navigation"). A word the page has only in its section does not count when its own title and description hold less than half of the query's words ("handle route events" is not "Social Event Voting", filed under Routing & Navigation). A page that only mentions the topic in passing is not listed; search_docs finds those.

Input Schema

NameRequiredDescriptionDefault
queryYesThe topic to look up in every SDK, e.g. "add markers".
limitPerSourceNoHow many matches to return per source.

Output Schema

NameRequiredDescriptionDefault
queryYes
topicYesThe query without platform and comparison words — what was looked up.
messageYesA one-line summary of the result.
sourcesYesEvery documentation source, in a fixed order.
unverifiedYesPlatform words left out of the topic that could not be checked against their platform's page titles (the index of `source` did not load), so one may be part of a feature name ("Android Auto") instead.
failedSourcesYesSource files that could not be loaded: "index" (llms.txt) or "full-text" (llms-full.txt) — a problem with the files on developer.magiclane.com or with reaching it, never a gap in the documentation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered; the description still adds real behavioral context beyond them, notably that every source returns a row and that a source reports "(no match)" rather than being omitted. It also discloses the per-source answer shape (side-by-side), which the caller could not infer from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The body is a single sprawling run-on laced with nested parentheticals and semicolon-chained exceptions, making it hard to parse even though the purpose statement is front-loaded. Much of the detail is arguably necessary spec, but it is delivered as an undifferentiated wall of clause stacking rather than structured rules.

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?

An output schema exists, so return shape need not be explained, and the description is unusually exhaustive about matching thresholds, fallbacks, and exclusion rules. The main residual gap is that limitPerSource's effect on output (up to 5 per source) is only in the schema, not the description.

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, but the description adds genuine semantics for the query parameter that the schema does not: platform names are ignored unless they are feature names ("Android Auto"), page titles, or the product itself ("REST API"). limitPerSource is left entirely to the schema, which is acceptable given its inline description.

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 opening clause gives a precise verb and resource ("Given one topic... return the best-matching documentation page(s) for EVERY source side by side") and explicitly enumerates the sources covered. It is clearly distinguishable from read_docs_batch, list_docs, and search_docs, which the description names as the tool for pages that only mention a topic in passing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the ideal use case ("cross-platform comparisons") and names an explicit alternative, search_docs, for loose mentions, which is genuine routing guidance. However, these cues are buried mid-paragraph rather than front-loaded, and there is no clear when-not-to-use framing against the other siblings such as get_product_guide or read_doc.

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