MCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavior beyond the annotations: the browser login requirement, the access-token/JWT input, the session-only vs permanent connection distinction, and the no-args link response. This is useful additional context and does not contradict the annotations.
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 longer than strictly necessary but every part contributes meaning: browser login, token usage, permanent header configuration, session-only login, and the no-args link behavior. It is front-loaded with the core purpose and remains reasonably concise.
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 one optional parameter, no output schema, and limited annotations, the description provides enough context to understand the auth flow, token lifecycle, and how to invoke the tool. It does not cover error cases or invalid-token behavior, but that is not critical for this simple 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?
The schema only defines an optional 'token' string with no description. The tool description fully compensates by stating that token is a JWT access token pasted by the user, that omitting it returns a login link, and that passing it creates a session-only login. This is complete for the single parameter.
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 identifies this as an authentication tool: it explains the browser login flow, the token input, and the no-args behavior to obtain a link. However, it does not explicitly contrast itself with sibling tools like 'connect', so there is no direct sibling differentiation.
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 gives explicit usage instructions: call with no args to get the login link, or call with { token: '<jwt>' } for session-only login. It also recommends a header-based permanent connection, which provides useful context. It does not explicitly state when not to use this tool or name alternative auth-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most build/workflow tools are clearly separated by resource and action, but some boundaries are blurry: expo_learn overlaps with expo_search_documentation/expo_read_documentation, and connect/toolkit_info/authenticate all touch connection and auth state. Agents may need to read descriptions carefully to avoid picking the wrong one.
The Expo-specific tools follow a strong expo_<domain>_<action> snake_case pattern, e.g., expo_build_cancel, expo_workflow_create, expo_search_documentation. The non-prefixed platform tools like authenticate, connect, marketplace, report_bug, and show_version break the pattern, but they read as a separate platform services group rather than random inconsistency.
25 tools is at the heavy end, but the scope is broad: EAS builds, EAS workflows, TestFlight, documentation, auth, and platform maintenance each contribute natural clusters of tools. A few generic helpers like marketplace and show_version could arguably live elsewhere, but the overall size is defensible.
The build lifecycle and workflow lifecycle are well covered: create/run/list/info/cancel/logs exist for workflows, and run/list/info/cancel/logs/submit exist for builds. Documentation search/read support is solid; minor gaps like removing or updating installed libraries and exposing EAS Update tooling prevent a perfect score.