Skip to main content
Glama
marvkr

Better Design

Get React Native Guide

get-react-native-guide
Read-onlyIdempotent

Load implementation guidance for React Native and Expo tasks, covering setup, routing, auth, native UI, testing, and release. Search by topic or query to get focused TypeScript recipes.

Instructions

Load implementation guidance for React Native and Expo projects.

Use this while planning, building, debugging, testing, or releasing a React Native app. It covers project setup, components and styling, Expo Router, data and authentication, native UI, animations and gestures, notifications, development builds, EAS workflows, testing, native modules, monetization, and store submission. It also includes copyable TypeScript and TSX recipes for secure sessions, validated API routes, purchases and usage credits, media sharing, realtime audio, durable generation, platform adapters, typed data clients, animation, chat interfaces, and social feeds. Preserve the examples when adapting them so the surrounding invariants remain visible to the coding agent.

The official Expo skills are included as a pinned, MIT-licensed source layer. They cover current Expo UI and Router APIs, project structure, networking, DOM components, web-to-native migration, native modules, brownfield apps, development clients, examples, App Clips, SDK upgrades, app-store delivery, EAS Hosting, Workflows, Observe, Update Insights, and remote simulators. Topics use the official- prefix, for example official-expo-native-ui and official-eas-app-stores. Paid EAS guides describe costs and plan limits; do not run a paid or state-changing command without the user's approval.

This complements the design tools: use get-ui-principle for visual decisions and get-ux-principle for product behavior.

You can either:

  1. Request a known topic: get-react-native-guide({ topic: "auth-session-recipes" })

  2. Use an alias: get-react-native-guide({ topic: "official expo native ui" })

  3. Search for the current task or code example: get-react-native-guide({ query: "code example for a notification action while the app is terminated" })

  4. Get the full topic index: get-react-native-guide({})

Prefer query search when you do not know the topic name. Use maxTokens to keep responses focused (recommended: 5000–10000).

Input Schema

NameRequiredDescriptionDefault
queryNoNatural language description of the React Native task or problem.
topicNoSpecific React Native topic or alias, e.g. auth-session-recipes, chat-component-recipes, development-builds, official-expo-native-ui, official-eas-app-stores.
contextNoOptional. One sentence on WHY you are calling this and what the user asked for (e.g. 'adding nav icons for the fintech dashboard'). Used only for usage analytics; does not change the result.
maxTokensNoMaximum tokens to return. Truncates content to fit. Recommended: 5000-10000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered structurally. The description adds value beyond that: it discloses that content truncates to maxTokens, that paid EAS guides contain cost and plan-limit information requiring user approval, and that examples should be preserved to keep invariants visible. It stops short of describing the shape of the returned content (prose vs. code blocks), which is the only remaining gap.

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 opening sentence is front-loaded and action-oriented, and the numbered call patterns are easy to scan. The middle paragraph enumerating Expo skill topics is a long undifferentiated list that partly duplicates what an empty-argument index call would return, which keeps it from a perfect score.

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 zero required parameters and no output schema, the description supplies everything an agent needs: content coverage, topic naming conventions, alias behavior, retrieval modes, token budgeting, cost caveats, and sibling routing. Nothing material is left for the agent to infer before calling it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description still adds real meaning: it shows four concrete invocation patterns (known topic, alias, natural-language query, empty call for the full index), explains that aliases normalize to topics via the `official-` prefix, and recommends a maxTokens range (5000–10000). That is meaningful guidance beyond the parameter definitions themselves.

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?

States a specific verb and resource ('Load implementation guidance for React Native and Expo projects') and immediately scopes what the guidance covers. It also distinguishes itself from nearby siblings by naming get-ui-principle for visual decisions and get-ux-principle for product behavior, so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Explicit when-to-use ('planning, building, debugging, testing, or releasing a React Native app'), explicit fallback rule ('Prefer query search when you do not know the topic name'), and an explicit sibling routing rule for design/UX questions. It also states a hard operational constraint: do not run paid or state-changing EAS commands without user approval.

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