Skip to main content
Glama
Sign In
magiclane

Magic Lane MCP Docs Server

Official
by magiclane
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get code examples from a Magic Lane documentation page

get_code_examples
Read-onlyIdempotent

Extract only the code blocks from a Magic Lane documentation page by URL or path, filtering by language tag or caption to skip the surrounding tutorial prose.

Instructions

Extract only the code blocks from a Magic Lane documentation page (by URL or /docs/... path), skipping the surrounding tutorial prose. Optionally filter by language tag (e.g. dart, kotlin, swift, cpp, typescript, json, shell) and by caption — the line that introduces a block, such as "Request Body" or "Response Body" on the REST API pages. Each block comes with its nearest heading and caption. Much cheaper than read_doc when only the sample code matters. Long pages are paged: the response says how many blocks remain and which offset continues; a block longer than the budget comes in parts. When a page has no matching block, the response names the languages it does have and the pages below it (or related pages, or for an example page the guides on its topic) that hold such blocks, with counts — listed unchecked when the page contents cannot be loaded, and not at all, saying so, when the index cannot be loaded in time.

Input Schema

NameRequiredDescriptionDefault
urlYesAbsolute developer.magiclane.com URL or a /docs/... path of the page.
offsetNoSkip this many matching blocks (for paging through pages with many examples). A block longer than maxChars is split into parts, and each part counts as one block here.
captionNoOnly return blocks whose caption — the label line introducing the block, e.g. "Request Body" or "Response Body (error code 200)" — contains this text (case-insensitive). Only labelled blocks match: on the REST API pages caption: "request" keeps the labelled request bodies; a request body that follows a field list without a label is not found this way.
languageNoOnly return blocks with this language tag (aliases like ts/kt/c++/yml are honoured).
maxCharsNoCharacter budget for the returned code (default 24000, at most 50000). A longer block is returned in parts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses real behavioral traits: long pages are paged with a stated remaining-count and offset, oversized blocks are returned in parts, and there are two degraded fallback modes when no block matches (listing languages/pages with counts; "listed unchecked" when contents can't load, silent-with-notice when the index times out). That is well beyond what the annotations convey.

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 purpose and the read_doc comparison are front-loaded, and every sentence carries operative information. The final sentence, however, is an over-packed clause chain ("listed unchecked when... and not at all, saying so, when...") that costs readability, and some caption/offset detail overlaps the schema.

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, the description carries the return-value burden itself: it explains that each block arrives with its nearest heading and caption, how paging metadata is reported, and what the response looks like when nothing matches. For a read-only extraction tool with 5 params, nothing an agent needs to call it correctly is missing.

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%, and the schema itself documents url/offset/caption/language/maxChars thoroughly, so the baseline is 3. The description still adds value by enumerating concrete language tags (dart, kotlin, swift, cpp, typescript, json, shell) where the schema has no enum, and by restating the caption concept with page-specific examples like "Request Body" on REST API pages.

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 precise verb+resource: "Extract only the code blocks from a Magic Lane documentation page", and explicitly contrasts with the sibling read_doc ("Much cheaper than read_doc when only the sample code matters"). It also states the input address form (URL or /docs/... path), so an agent can immediately tell this apart from read_doc or search_docs.

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 names the alternative (read_doc) and the condition that selects this tool: when only the sample code matters. It also implies when-not use via "skipping the surrounding tutorial prose". There is no explicit exclusion for the other siblings (find_across_sdks, search_docs), so it stops short of a full routing guide.

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