Skip to main content
Glama
Sign In
fregggggo

react-native-eye

by fregggggo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Evaluate JS

eval_js

Evaluate JavaScript in a running React Native app's runtime and return results, including awaited promises. Run long work as background jobs and collect output later.

Instructions

Evaluate JavaScript in the app's runtime and return the result. Statements are allowed, and a promise result is awaited (await fetch(...), AsyncStorage.getItem(...)) — pass the promise itself, not await (Hermes has no async/await in evaluated code). Pass background: true for work that outlives one tool call (a long measurement, a snippet that samples for 30s) and collect the result with get_job.

Input Schema

NameRequiredDescriptionDefault
codeYes
labelNoName for a background job, shown by get_job.
backgroundNoStart the evaluation and return a job id immediately instead of waiting for the result.
timeout_msNoHow long to wait for a promise result (default 10000; background jobs default to 600000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses promise awaiting, the Hermes no-async/await constraint, and the semantics of background mode and result collection. It omits the most consequential trait — that this executes arbitrary code in the app with side effects and potential to mutate app state.

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?

Front-loaded with the core purpose, then constraint details in a tight sequence. The parenthetical examples earn their place by showing valid promise usage, though the sentence structure is slightly dense and runs together multiple 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?

No output schema exists, and the description plus schema together convey the return behavior (immediate result vs job id). What is missing is safety/error context — whether failures throw, what happens on timeout — which matters for an arbitrary-code-execution tool.

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 75%, and the description meaningfully supplements it: it explains what background: true does behaviorally and how its result is retrieved, beyond the schema's 'return a job id immediately'. 'code' and 'label' are left to the schema, which is acceptable at this coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Evaluate JavaScript in the app's runtime and return the result'), which is unambiguous. It does not, however, distinguish itself from sibling 'profile_js', which likely also executes JS, leaving the agent to infer the boundary.

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 concrete guidance on when to pass a promise vs await, and explicitly says to use background: true for work outliving one call and to collect via get_job — naming a sibling correctly. It stops short of saying when NOT to use this tool or how it differs from profile_js/get_state.

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