extentos

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.11.57
Disambiguation5/5
Each tool has a clearly distinct purpose, supported by detailed descriptions that specify when to use and not use them. Even closely related tools like injectTranscript, injectAssistantUtterance, and assertToolCalled are well-differentiated by their target phase and behavior.
Naming Consistency4/5
Most tool names follow a consistent verb_noun pattern (e.g., getPlatformInfo, createSimulatorSession, setSimVideo). A few compound names like regenerateConnectionPageFile deviate slightly, but overall the pattern is predictable and readable.
Tool Count3/5
With 37 tools, the count is high but appropriate for the broad scope of the server, which spans project scaffolding, configuration, simulator management, testing, analytics, and production readiness. Each tool serves a specific need, though some consolidation could be possible.
Completeness5/5
The tool surface is comprehensive, covering the entire development lifecycle from project initialization and capability discovery to integration validation, simulator testing, credential management, and production checklist. There are no obvious gaps in core workflows.
Average 4.7/5 across 37 of 37 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on August 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that it returns DisplayNode tree, selectable node ids, node count, root kind, and explains the source is live in-memory hub snapshot, exact and immediate. This is thorough for a read-only operation, though it could mention what happens if session does not exist or if display has never been shown.
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 description is detailed and well-structured, with clear sections covering purpose, output, source, and usage flow. It is somewhat long but every sentence adds value. Could be slightly more concise, but overall efficient.
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?
Given the complexity (no output schema, one parameter), the description covers output (DisplayNode tree, selectable ids, etc.), usage context, and pairing with injectInput. It lacks parameter description but is otherwise complete for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (sessionId) with 0% schema description coverage. The description does not explain what sessionId is or how to obtain it. Given the lack of coverage, the description should at least describe the parameter's purpose, but it does not.
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 clearly states it reads the currently rendered display on simulated glasses, specifying the track (track 5) and native capability. It distinguishes from siblings by mentioning pairs with injectInput and not for event history (getEventLog) or non-display state (getSimulatorStatus).
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 guidance on when to use: to confirm a display rendered, read structure, or find selectable ids before injectInput. Also clearly states what not to use for: display event history (use getEventLog) or non-display session state (use getSimulatorStatus). Provides a usage flow with createSimulatorSession, getDisplayState, injectInput, getDisplayState again.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, the description bears full responsibility. It discloses file size limit (<1 MB), allowed formats (MP3/M4A/AAC/WAV), activation timing (after next assistant start), cross-device availability, dashboard appearance, collision rules (registerSound wins), and error cases (403, 401). Missing explicit success return, but overall very transparent.
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 description is well-structured and informative. It starts with purpose, then constraints, then usage guidelines. Every sentence adds value without being overly verbose. Could be slightly trimmed, but it earns its length. Score 4 for good efficiency.
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?
Given that there is no output schema and three parameters, the description covers the tool's purpose, constraints, behavioral nuances, error scenarios, and usage boundaries comprehensively. It even explains SDK behavior and dashboard appearance. Nothing essential is missing for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description reinforces the meaning by giving examples and context (e.g., name is 'play-by-name key', filePath relative/absolute, appPackage is 'project_install_id'). It adds marginal extra value beyond the schema, so a score of 3 is appropriate.
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 starts with a clear verb and resource: 'Upload a local audio file into a project's named-sound library.' It distinguishes itself from sibling tools by explicitly stating what it is for (provisioning UI sounds) and what it is not for (assistant voice, local bundle sounds), making the purpose unambiguous.
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?
The description provides explicit when-to-use and when-not-to-use guidance: 'USE to provision an app's UI sounds while building it' and 'DON'T USE for the assistant's VOICE (that's setAssistantConfig) or for sounds the app should bundle locally (registerSound in app code needs no upload).' It also states prerequisites (linked Extentos account, MCP access grant).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the tool is read-only, explains the managed/unmanaged behavior and its implications for source of truth, and describes the relationship with regenerateConnectionPageFile. No annotations provided, so the description carries the burden and does well.
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 description is well-structured with clear sections and uses bold for emphasis. It is slightly verbose but each sentence adds value. Could be slightly more concise, but still effective.
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?
Given one parameter and no output schema, the description fully covers the tool's purpose, return shape, and behavioral implications. It also relates to sibling tools, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter appPackage has a clear schema description (minLength, example). The tool description does not add extra semantics beyond what the schema provides. Schema coverage is 100%, so baseline 3 is appropriate.
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 clearly states the tool reads the per-project ExtentosConnectionPage config, specifies the return structure ({ managed, config }), and explains the managed flag. It distinguishes from sibling tools like setConnectionPageConfig and regenerateConnectionPageFile.
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?
Explicitly says when to use (inspect dashboard-driven config or before regenerateConnectionPageFile) and when not to use (to change, use setConnectionPageConfig). Provides clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format, the fact that the SDK does not automatically play sounds, the gating and permission errors (403, 401), and the auth requirement. It could be more explicit about being a read-only operation with no side effects, but it is largely transparent.
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 description is relatively long but every sentence provides value. It is structured: purpose, return format, behavioral context, gating/auth, usage guidance. It is front-loaded with purpose. Could be slightly more concise, but still well-organized.
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?
Given the tool has no output schema, the description fully explains the return structure, behavioral details, prerequisites, error conditions, and usage context. It also distinguishes from relevant sibling tools. Completely sufficient for an agent to decide when and how to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter). The description does not add new meaning beyond the schema's description of `appPackage`. Baseline is 3, and the description meets that without adding further parameter semantics.
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 clearly states 'List a project's named-sound library' with a specific verb and resource. It explicitly distinguishes from the sibling tool addProjectSound by stating 'DON'T USE to add sounds (use addProjectSound).'
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?
The description provides explicit guidance: 'USE to see which sound names app code can play, or before adding a sound to avoid a duplicate name. DON'T USE to add sounds (use addProjectSound).' It also mentions prerequisites like a linked Extentos account and access grant permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses persistent side effects (writing to ~/.extentos/auth.json), error conditions (unknown_device_code, auth_timeout), and the polling mechanism. Minor gap: doesn't detail behavior if called multiple times with same deviceCode after success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, well-structured paragraph. It front-loads the primary action, uses bold for important notes, and every sentence adds value. No redundancy.
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?
For a tool with no output schema, the description adequately explains the flow, expected outcomes (token persisted), and error handling. It references the relevant sibling tool createSimulatorSession, providing complete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds context on the source of deviceCode and default/clamping behaviors for maxWaitSeconds and pollIntervalSeconds, but largely reiterates schema info. Baseline 3 is appropriate.
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 clearly states the tool's purpose: polling the backend to complete user signup and persist a bearer token. It distinguishes itself from the sibling tool createSimulatorSession, which handles auth inline, by specifying when this tool is needed.
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?
Explicitly states when to use: after createSimulatorSession returns 'auth_required' with autoLink:false or after a timeout. Also warns against preemptive use and highlights that autoLink handles it by default in bundle 10+.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It fully discloses that 'status is guidance, not a measurement', that 'ready means nothing left on this list, NOT Extentos verified your app', and explains which steps are project-derived. It also clarifies that identical output before and after doing work is expected. However, it does not mention rate limits or potential performance implications of calling the tool.
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 description is comprehensive but somewhat lengthy. It is front-loaded with the return structure and purpose, then dives into conditional behavior. Every sentence adds value, but the extensive detail could be streamlined slightly without losing clarity. The use of bold and cross-references is helpful for structure.
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?
Given the tool has 5 parameters (2 required), no output schema, and no annotations, the description covers behavioral expectations, return format, conditional logic, and limitations well. It could be improved by noting output size or performance considerations, but overall it is sufficiently complete for an agent to use correctly.
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?
The schema description coverage is 80%, meaning most parameters are already described in the schema. The description adds value by explaining the behavioral interactions between parameters (e.g., 'handlers' labels the API Keys step but does not trigger it alone; 'services' is the trigger). It also gives context on how 'projectPath' affects step status. The description does not detail the enum values for 'platform' beyond what the schema provides, but the added semantic ties between parameters are significant.
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 specifies the tool returns a personalized production-readiness checklist based on SDK capabilities, handlers, and BYOK services. It clearly distinguishes the verb 'return' and resource 'checklist', and the cross-links to siblings like 'getPermissions' and 'validateIntegration' help differentiate its purpose from those tools.
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?
The description explicitly states 'USE when going to production. DON'T USE during development.' It also provides cross-links and conditions (e.g., 'for checks that genuinely inspect the project use validateIntegration'), offering clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool does NOT report active streams, explains why fields were removed, and describes the freshness advisory. This is thorough and honest about limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but verbose (around 150 words). It front-loads the main purpose, but contains detailed explanations that could be shortened or moved to separate documentation. It earns its sentences but lacks conciseness.
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?
Given no output schema, the description thoroughly explains the return value (phase, hardware-ready, roles, testVideos, freshness advisory) and what it does not return. It is complete for an agent to understand what information the tool provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explicitly describe the sessionId parameter beyond context. While the parameter is simple and inferable from the tool purpose, the description misses an opportunity to add explicit meaning, such as format or source.
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 uses a clear verb-resource structure ('Read a live simulator session's current state') and lists specific return fields. It explicitly distinguishes from siblings like getEventLog, helping the agent select the right tool.
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?
The description provides explicit usage guidance: 'USE during testing to confirm...' and 'DON'T USE for event traces (use getEventLog)'. It also explains when to check for stale connections, giving clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the generation direction, the returned file structure with a _comment marker and warning against hand-editing, the drift note behavior when projectPath is given, and the platform limitation. It does not explicitly mention idempotency or required permissions, but overall it is fairly transparent.
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 description is about 6 sentences, each providing necessary context. It is front-loaded with the main action and distinguishes from siblings. While slightly verbose, it is efficient and well-structured, earning a 4.
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?
Given no output schema, the description adequately explains the return value (file object with path, content, _comment marker) and the offline theming purpose. It covers the key scenarios and platform limitations. However, it could mention error cases (e.g., unknown appPackage), but overall it is fairly complete.
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 baseline is 3. The description adds value by clarifying the platform default and iOS constraint, and by explaining the optional projectPath enables a drift note. This goes beyond the schema descriptions, justifying a 4.
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 clearly states the verb 'Regenerate' and the resource 'committed extentos.connection-page.json', and explains the direction (from server config to file). It distinguishes from the sibling tool adoptConnectionPageFile, which does the reverse direction. The purpose is specific and unambiguous.
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 usage guidance is provided: 'USE after setConnectionPageConfig / dashboard edits to sync the repo. DON'T USE to push local edits up (use adoptConnectionPageFile).' It also notes that the tool is Android-only and that unmanaged projects have nothing to mirror. This gives clear when-to-use and when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds. It discloses persistence ('change persists on the session'), live propagation ('pushed live to a connected app without a reconnect'), event generation ('device_changed event lands in getEventLog'), and capability effects ('drives glasses.display.isAvailable'). It also explains the no-display degradation behavior, making the tool's side effects highly transparent.
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 description is dense and information-rich, with every sentence providing actionable detail. It is quite long and runs as a single unbroken block, and there is some repetition (e.g., display/no-display classification). It is appropriately sized for the tool's complexity but not maximally scannable.
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?
The description is highly complete: purpose, usage, behavior, persistence, eventing, and alternatives are all covered, which is impressive for a tool with no annotations or output schema. The omission of the brilliant models and the platform-switching refusal behavior (noted only in the schema) is a minor gap, and there is no mention of the return value, but overall the context is robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the 'device' parameter (display panel differences, testing implications, identity surface), going beyond the schema. However, it omits two valid enum values (brilliant_halo, brilliant_frame) and incorrectly states only 'eight' simulatable models, creating an inconsistency with the schema. sessionId gets no explanatory value, but it is a standard identifier.
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 clearly states the action ('Switch the simulated glasses DEVICE MODEL') and the resource ('simulated glasses'), making the tool's purpose immediately obvious. It also distinguishes the tool from siblings by explicitly saying DON'T USE for camera scene (setSimVideo) or voice (injectTranscript), which is strong differentiation. The minor miscount of 'eight' models versus the ten in the schema does not obscure the core purpose.
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?
The description gives explicit when-to-use guidance ('USE before driving a display flow', 'test BOTH branches of a capability-gated feature headless') and when-not-to-use ('DON'T USE for the camera scene or voice'), even naming alternative tools. This is the gold standard for usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool is account-scoped and read-only, requires login (401 returns account_required), and explains the managed flag and runtime precedence. Also mentions SDK consumption behavior.
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 description is comprehensive but not overly verbose. It is structured logically with clear sections. A minor deduction for length, but every sentence contributes value.
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?
Despite no output schema, the description thoroughly explains the return structure (managed, config, options, etc.), auth requirements, runtime precedence, and consumption by SDKs. Covers all essential context for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (appPackage) with full schema coverage (100%). The description reiterates the parameter but adds minimal new semantic meaning beyond the schema description. Baseline 3 is appropriate.
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 clearly states the tool reads per-project assistant settings (models, voice, memory) and returns a structured response. It distinguishes from sibling tools like setAssistantConfig (change) and getGatewayUsage (usage/cost).
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?
Explicitly states when to use: to view current config or discover valid option ids before recommending a change. Also explicitly states when not to use: for changing config (use setAssistantConfig) or for usage/cost (use getGatewayUsage). Includes auth prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses return content (minimal Kotlin + Swift snippet, gotchas, related getCodeExample patterns) and limitations ('minimal', 'typically cover it'). It doesn't explicitly state read-only behavior, but the guide nature implies non-mutation, and no hidden side effects are indicated.
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 a clear purpose, followed by relationship to siblings, coverage list, and usage guidance. The 'Covers' feature list partially duplicates the schema enum, but adds semantic grouping that aids understanding. The USE/DON'T USE sections are succinct and effective.
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?
No output schema, but description fully explains return content and boundaries. It covers what the tool does, when to use it, when not to, and how it relates to siblings. For a lookup guide with one parameter, the description is comprehensive and complete.
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% (enum + description referencing getPlatformInfo.features[].name). Description adds value by semantically grouping feature types (lower-level primitives vs assistant runtime) and advising to start with 'assistant_runtime' for voice-assistant apps, which helps parameter selection beyond the schema.
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 explicitly defines the tool as a 'Per-feature SDK usage guide' with Kotlin/Swift snippets, gotchas, and related code patterns. It distinguishes from siblings by stating it adds 'the actual idiom' for feature usage, while getPlatformInfo only lists names/categories and getCodeExample provides full patterns.
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?
Provides clear USE conditions ('when you know which feature you need but don't know the canonical call shape, or when you're hitting a confusing failure') and explicitly names alternatives for DON'T USE cases (getCodeExample for compositional patterns, getPlatformInfo for capability discovery).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, that secrets are never exposed, account-scoping requiring linked Extentos account, and permission gating (Credentials access grant). Details error responses (401, 403) for authentication and authorization failures. No contradictions with annotations (none provided).
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?
Description is front-loaded with core functionality and return shape, then adds important caveats and usage guidance. While slightly verbose, every sentence provides value. Could be marginally tighter but still well-structured.
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?
For a tool with no output schema, the description covers return shape, error conditions, authentication requirements, permission model, and usage context. It is fully self-contained and provides all necessary information for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the single required parameter 'appPackage' as 'The app\'s package / bundle id (project_install_id).' The description does not add additional parameter-level information beyond what the schema provides, but schema coverage is 100% so baseline 3 is appropriate.
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?
Clearly states the tool reads whether a project's Meta DAT build identity is set, plus a masked hint and update time. Specifies the return structure. Distinguishes from siblings by explicitly stating not to use for reading secret values and directs to setCredential for adding.
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?
Explicitly says when to use (check before recommending setup, confirm after setCredential) and when not to use (never to read a secret value). Provides alternative tool (setCredential) for adding credentials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the default response is 'COMPACT' (~2KB), that expand can opt into 'capabilities.full', that glasses is optional defaulting to meta, and that android_xr is preview. It doesn't explicitly say 'read-only' but 'return static metadata' implies no side effects. No contradiction with annotations exists.
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 description is long but well-structured with bold key phrases, bullets, and clear USE/DON'T USE markers. It front-loads the core purpose and then packs decision-relevant context. While it could be trimmed, each sentence earns its place by steering the agent toward correct tool selection and parameter choices.
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?
Given no output schema and no annotations, the description provides a complete picture: default response shape, expansion options, vendor defaults, integration path guidance, and pointers to related tools for feature guides, code examples, and docs. It leaves little ambiguity about what to expect and how to proceed.
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 67% (2/3 params described). The description adds significant nuance beyond the schema for glasses ('defaults to meta', 'android_xr preview', 'meta_rayban legacy', 'vendorless baseline needs no value') and for expand (references capabilities.full and compact default). The sections parameter is not explicitly described, but its values ('version', 'capabilities') are implied by the opening line about library version and capability list.
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 clear, specific statement: 'Return static platform metadata: library version + the list of SDK capabilities the glasses expose.' This uses a specific verb and resource, and immediately distinguishes itself from sibling tools by positioning itself as the 'right first call for any new task' while pointing to getCapabilityGuide, getCodeExample, and searchDocs for deeper detail.
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?
Extremely explicit usage guidance is provided: 'USE at session start before scaffolding or writing handler code' and 'DON'T USE for what's installed in the project (use inspectIntegration).' It also describes the two integration paths (voice vs camera/display), tells the developer which path to choose based on requirements, and names alternatives like getMigrationGuide for existing Meta DAT users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: loads video as cameraSource, same code path as drag-drop, emits lifecycle event, requires browser role attached, and is idempotent with ensureSimulatorBrowser.
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 purpose, all sentences add value, but could be slightly more concise; still well-structured.
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?
Given no annotations and no output schema, the description provides complete context: purpose, prerequisites, discovery method, when/not to use, and relation to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning for videoId (where to get it, fields) beyond schema, but sessionId parameter lacks description in both schema and description, despite being required.
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 clearly states it pipes a test video into the simulator's camera input so capture_photo/capture_video/videoFrames use a known scene, distinguishing it from siblings like injectTranscript.
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?
Explicitly says 'USE before triggering a capture_photo/capture_video flow that needs a scene' and 'DON'T USE to upload new videos', plus describes prerequisite of browser tab connection and suggests ensureSimulatorBrowser.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers richly. It discloses the severity model, return object shape, the meaning of 'valid' and 'summary', the warning-to-review demotion, the runtime source of truth for permissions, and that the project key is checked for shape not just presence. This goes far beyond a simple mutability hint.
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 description is long but every sentence contributes substantive detail—no filler. It is front-loaded with the core purpose ('Pre-test gate') and then methodically enumerates checks and behaviors. The length is justified by the tool's complexity, though it could arguably be trimmed into bullet points without losing information.
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?
Despite no output schema, the description fully explains the return structure, severity semantics, and interpretation of results. It also covers edge cases (voice-only apps, derived permissions, runtime source of truth) and integrates with sibling tools, making it complete for an AI agent to invoke and interpret correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description already covers the single parameter (projectPath) at 100%, so the baseline is 3. The description adds a small nuance about passing it explicitly when the project isn't the cwd, but this largely restates the schema. No extra parameter meaning is needed beyond what the schema provides.
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 clearly identifies validateIntegration as a 'Pre-test gate' running severity-tiered checks across the project, enumerating the major check categories and explicitly distinguishing it from sibling tools like inspectIntegration. The specific verb 'validate' plus the detailed list of checks leaves no ambiguity about the tool's purpose.
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?
Usage guidance is explicit: 'USE after making changes, before testing' and 'DON'T USE for reading state without judging it (use inspectIntegration).' It also clarifies that only generateConnectionModule mints the project key, preventing misuse. This is the gold standard for when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes polling every 200ms from a fixed anchor, matching logic, timeout behavior, and the fixed-anchor re-scan guarantee. It does not explicitly state read-only nature but that is inferred.
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 description is somewhat lengthy but every sentence is informative and earned. It is front-loaded with the core purpose and structured logically. Could be slightly more concise, but no redundancy.
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?
Given the tool's complexity and no output schema, the description fully covers return values (matched event payload or error), internal behavior (polling, fixed anchor), and rationale for design choices. No gaps.
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 80%, and description adds critical context for all parameters: name's matching semantics, argsMatch's partial top-level matching, timeoutMs defaults and provider-specific advice, and sinceCursor's role in preventing race conditions. This goes beyond schema.
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 clearly states the tool waits for an 'assistant.tool_called' event matching a given name with optional argsMatch. It uses specific verbs and resources, and distinguishes itself from siblings like getEventLog and inspectIntegration.
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?
Explicitly states when to use (right after injectAssistantUtterance in E2E loop) and when not to use (for full event trace or static registration). Also explains the critical sinceCursor parameter and provides guidance on timeoutMs based on providers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 so thoroughly. It discloses get-or-create semantics, the one-sim-per-project model, autoBind attached vs URL-bake fallback, auto-polling of completeAuthLink with re-mint on success, and the platform constraint that android_xr is Android-only. It even warns about the unbound-sim pitfall when projectPath is omitted.
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 description is long but well-structured with bolded section headers and each paragraph addresses a distinct concern. It is front-loaded with the core get-or-create purpose, then dives into lifecycle, identity, auto-bind, and auth. While lengthy, every sentence contributes meaningful information for a complex tool with no annotations.
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?
The description comprehensively covers purpose, lifecycle, idempotency, auth flow, platform constraints, and pitfalls like the projectPath omission. It omits semantics for three parameters (platform, recordBinary, autoOpenBrowser) and does not describe the full return shape beyond status and autoBind, but overall it is unusually complete for an un-annotated 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 57%, and the description adds significant meaning for four of seven parameters: glasses (vendor/experimental status, platform constraint), autoLink (internal polling behavior, default), projectPath (binding semantics, fallback to cwd), and autoLinkSeconds (clamping). However, platform, recordBinary, and autoOpenBrowser are left undocumented in both schema and description, preventing a 5.
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 'Get-or-create' and clearly states it provisions a browser-based simulator session or returns the existing saved one. It also distinguishes itself from sibling tools like deleteSimulatorSession by explicitly explaining the two-step rotation process, making its purpose unambiguous.
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?
It explicitly says 'DO NOT call this per change' and explains that app-code edits rebuild automatically, so repeated calls are unnecessary. It also instructs users to call deleteSimulatorSession before re-minting and recommends autoLink:false for CI contexts, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It clearly states what the tool returns ('full Kotlin + Swift code, an explanation, gotchas, and the SDK features it exercises') and clarifies a key potential misperception about byok_anthropic (not related to the assistant runtime). It does not cover rate limits or auth, but this is a reference retrieval tool with no mutation, so the transparency level is strong.
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 description is long, but the tool exposes 13 distinct patterns that each require explanation. The opening sentence is clear and purposeful, and the bulk organizes usage recommendations by bolded alternatives. While it could benefit from a bullet list, the density is justified and front-loaded with the most important direction ('start with assistant_agent_loop').
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?
Despite having no output schema, the description discloses return contents and maps every pattern to its intended use context. It even explains that the pattern affects the example's code shape and verification approach, and covers when not to use the tool. The description is effectively a complete usage guide for the tool.
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?
Although the schema covers the single `pattern` parameter with an enum, the description provides deep semantics for nearly every enum value, explaining what each pattern is for, when to use it, and how it relates to others. This goes far beyond the schema's tiny one-line description, making the parameter choices much more meaningful.
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 'Reference library — retrieve a complete SDK code example (Kotlin + Swift) for a use case', providing a specific verb and resource. It immediately names recommended sibling patterns (assistant_agent_loop, agent_driven_e2e_full_loop) and distinguishes them from fine-grained alternatives, clearly differentiating this tool from siblings.
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 guidance is given: 'USE when you're about to write handler code...' and 'DON'T USE for capability discovery (use getPlatformInfo) or per-feature minimal usage (use getCapabilityGuide)'. It also explains when to choose each pattern relative to alternatives (e.g., 'For the dedicated agent-side test workflow... agent_driven_e2e_full_loop').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, required linked account (401 error), metadata-only (no transcripts/audio), and what is/isn't metered. Since no annotations exist, description fully covers behavioral traits.
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 main purpose, returns format explained, then constraints and usage guidelines. Slightly long but every sentence adds new information; no redundancy.
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?
Explains return object shape (window, totals, byModel, creditBalanceUsd), error case (401), and pairing suggestion. No output schema needed; missing only minor details like rate limits or pagination (likely not needed).
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% but description adds value: default value for 'days' (30), bucketing auto-scaling rules, clarifies 'appPackage' as project_install_id. Exceeds baseline 3.
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?
Clearly states verb 'Read' and resource 'account-scoped managed-AI-gateway usage + exact cost'. Distinguishes from siblings by specifying managed-gateway scope and contrasting with direct OpenAI calls.
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?
Explicitly provides USE cases (report spend, dominant model, cost-driven recommendation) and DON'T USE cases (live traces → getEventLog, config changes → setAssistantConfig), with sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It thoroughly discloses provider routing (OpenAi vs Mock), costs, latency, mock argument behavior (empty object), deferred audioWavBase64, wake requirement (no auto-wake), and return value (watchCursor). This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and detailed, which impacts conciseness. However, it is well-structured with bold headers, bullet points, and code-like steps. It front-loads the purpose and usage, but the length may hinder quick scanning.
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?
Given the tool's complexity, the absence of output schema, and moderate schema coverage, the description is exceptionally complete. It covers purpose, usage, behavioral nuances, parameter details, return value, dependencies, and exclusions. The example usage pattern ties it all together.
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 67%, so baseline is 3. The description adds significant meaning: for `text`, it explains provider-specific routing and mock matching; for `audioWavBase64`, it clarifies deferred status and intended path; for `sessionId`, it implies use from `createSimulatorSession`. The description compensates well.
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 clearly states the tool's purpose: 'drive an assistant turn from outside the live session for agent-driven E2E tests'. It specifies the verb (inject) and resource (assistant utterance), and distinguishes it from sibling `injectTranscript` by mentioning Phase 4 vs Phase 3.
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?
The description provides explicit usage instructions: 'USE in the agent E2E loop: createSimulatorSession → injectTranscript → ... → injectAssistantUtterance → assertToolCalled' and 'DON'T USE for Phase 3 glasses.conversation.onWake flows — that's still injectTranscript's domain'. It also explains the wake requirement and how to use with `assertToolCalled`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses making the app MANAGED, validation behavior (warnings for unknown keys not blocked), post-write action ('run regenerateConnectionPageFile'), and error handling (401 with account_required hint). No annotations present so description carries full burden.
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?
Somewhat long but every sentence adds essential information; front-loaded with key purpose. Could be slightly more structured but remains efficient.
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?
Covers prerequisites, behavior, post-write action, and error cases. Lacks explicit return value description, but for a mutation tool without output schema, this is acceptable. Complete enough given complexity.
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%, but description adds context: explains config structure, that omitted fields become null and SDK fills defaults, and identifies appPackage as bundle id. Adds meaningful value beyond schema.
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 clearly states the tool persists ExtentosConnectionPage config (theming and section visibility) and distinguishes it from siblings like getConnectionPageConfig (read) and regenerateConnectionPageFile (post-write mirror).
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?
Explicitly says when to use ('to author/update connection-page theming'), when not to (just to read, use getConnectionPageConfig), and prerequisites (linked Extentos account, login hint).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers key behaviors: drift protection (needs_confirmation flow), required login, Android-only limitation, and that it reads a specific file. No contradictions.
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?
Thorough but efficient; each sentence adds value. Slightly long but front-loaded with core action. No wasted words.
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?
Given no output schema or annotations, the description provides complete context: prerequisites, drift flow, platform limitations, and parameter roles. Sufficient for an agent to use correctly.
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 covers 100% of parameters. Description adds value by explaining confirm's role in overwriting, platform default, and that projectPath reads a specific file. Justifies 4 due to added context beyond schema.
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?
Clearly states the tool seeds a committed file to the server, distinguishing it from siblings like setConnectionPageConfig and regenerateConnectionPageFile by specifying use cases.
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?
Explicitly says 'USE to seed an existing committed theme' and 'DON'T USE for routine edits', providing clear when-to-use and when-not-to-use guidance, plus mentions drift protection and login requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: idempotent, no redundant tab, checks authoritative hub liveness, opens browser directly, polls, handles errors, and explains autoOpen:false case for headless. It even notes that hub rejects second live browser. Comprehensive.
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 description is lengthy but well-structured and front-loaded. Every sentence adds value, explaining behavior, usage, and edge cases. It could be slightly more concise but given the complexity, it earns a 4.
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?
The description covers return object shape, error conditions, when to call, and behavioral differences from siblings. It explains the lag in getSimulatorStatus and the authoritative hub check. For a tool with 3 params and no output schema, this is outstandingly complete.
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 67% (autoOpen and timeoutMs described), and the description adds meaningful context: autoOpen:false gives immediate snapshot without spawn, timeoutMs has default and clamp range. SessionId lacks description but is required and minimal. Overall enhances understanding beyond schema.
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 clearly states the tool ensures a connected simulator browser tab, opening one if needed and confirming WebSocket attachment. It specifies the resource (simulator browser tab) and action (ensure connection), and distinguishes from siblings like getSimulatorStatus which check app/hardware state.
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?
The description provides explicit when-to-use guidance: after createSimulatorSession, after backend deploy, after tab close, or when reported not attached. It also explicitly says when NOT to use: for app/hardware state, directing to getSimulatorStatus. This is exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it is a read-only guide that returns structured credential setup info. It reveals that Meta DAT credentials are only needed for real hardware, not simulator. The return structure is detailed (metaCredentials, serviceCredentials, etc.) with no hidden side effects.
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 description is well-structured and front-loaded with the main purpose. It is somewhat lengthy but every sentence adds value. Could be slightly more concise, but overall efficient for the amount of detail.
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?
The description is complete for a guide tool: no output schema exists, but the return structure is fully detailed. It also provides usage context, cross-links, and platform-specific guidance. All relevant aspects are covered.
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 67%, and the description adds meaning beyond the schema: it explains that omitting services returns a Meta-DAT-only guide, and clarifies handler matching by name patterns. The platform parameter is not described in schema or description beyond being required, but context is sufficient.
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 clearly states the tool returns step-by-step credential setup for Meta DAT build identity and BYOK providers. It specifies the verb 'return' and the resource 'credential setup', distinguishing it from sibling tools like getCredentialStatus/setCredential by noting they are for the account-vaulted path.
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?
Explicitly states when to use: 'when wiring a new BYOK provider or graduating from simulator to real hardware.' Also states when not to use: 'DON'T USE during the simulator-only dev loop.' Provides cross-links to related tools for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden—and it delivers. It discloses the WebSocket relay scope, BYOK invisibility and the observability wrapper, the chip grouping behavior including errors absorbing severity≥warn events, the follow blocking behavior, cursor bookmark semantics, and retired event types (ai chip, Phase 3 conversation runtime). No contradictions with annotations (none present).
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 description is long but well-structured and front-loaded with the core purpose. It stays scannable via USE/DON'T USE callouts, bolded scope, and short paragraphs. Some duplication exists between the description and the filter schema's description (e.g., ai chip retirement), but overall each sentence adds substantive guidance; it could be tightened, yet complexity justifies the length.
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?
Despite having no output schema, the description covers the full context an agent needs: event grouping and meanings, severity rules, BYOK visibility and wrapper, follow/cursor tailing with timing details, and a reference to getCodeExample('agent_test_loop'). It also addresses edge cases like combined voice and voice errors requiring separate fetches, making it complete for its complexity.
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 56%, and the description adds meaningful semantics beyond the schema for the most important parameters: filter, follow, cursor, and collapseRepeats. It explains chip meanings, event types, and the live-watch loop. However, some parameters like redactBinary and responseFormat are not explained in the description or schema, leaving a small gap.
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 specific verb and resource: 'Fetch structured event trace inside a simulator session' and immediately states its primary diagnostic purpose. It also distinguishes this tool from siblings by explicitly naming validateIntegration and getSimulatorStatus as alternative tools for other use cases.
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?
The description gives explicit when-to-use and when-not-to-use guidance: 'USE to diagnose which capability primitive is misbehaving. DON'T USE for static configuration checking (use validateIntegration) or for live session phase (use getSimulatorStatus).' It also covers the subtle BYOK wrapper case and live-follow pattern, giving clear context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that migration is a call-site swap, not a rewrite; returns a map keyed by DAT symbol; re-embeds no code; provides an ordered cutover plan orchestrating other tools; clearly states that coexistence is not supported. No annotations exist, so the description carries full burden and meets it thoroughly.
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 description is long but every sentence adds value; it is front-loaded with purpose and structured with clear sections. Slightly verbose but justified by the complexity of the tool.
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?
Despite no output schema or annotations, the description fully covers the return value structure, the migration plan, links to other tools, and scope limitations. It is complete for a complex 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 100% (single parameter with enum and description). The description adds value by explaining the default behavior (defaults to meta_dat) and forward-compatibility of the enum, going beyond the schema's documentation.
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 clearly states it is the entry point for developers migrating from Meta DAT to Extentos SDK, specifying the output (mapping from DAT symbol to Extentos primitive) and scope (full cutover, not coexistence). It distinguishes from sibling tools like getCapabilityGuide and getCodeExample by positioning itself as the starting point.
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?
Explicitly states when to use (project with existing DAT imports) and when not to use (greenfield project with no DAT code), and provides an alternative starting point (getPlatformInfo → generateConnectionModule) for the latter case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers richly. It discloses critical behavioral traits: runtimeGrants is 'the half that is not a manifest entry,' the platform argument 'does NOT filter the response,' and capabilities needing no permission 'are accepted silently — they never error.' It even explains the consequence of skipping runtime grants (mute app).
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 description is long but well-structured with backticked field names and explicit blocks. Every sentence earns its place given the complexity of the tool. It is front-loaded with the core purpose before diving into details. Slightly dense, but appropriate for the information density required.
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?
Despite no output schema, the description fully enumerates the return structure: '{ android, ios, metaDat, runtimeGrants, summary }' with subfields. It also covers edge cases (silent acceptance, platform non-filtering, runtime grant implications). For a tool with this complexity, the description leaves no critical gaps.
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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by giving concrete capability examples and explaining that the platform argument only shapes the summary line, not the response. However, the schema already covers the core semantics of both parameters, so the extra information is enhancement rather than necessity.
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 'Derive the Android permissions, iOS Info.plist keys, Meta DAT scopes, AND the runtime grants a list of SDK capabilities requires,' which is a specific verb+resource statement. It explicitly distinguishes from sibling tools by ending with 'DON'T USE for capability discovery (use getPlatformInfo).'
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?
Explicitly states when to use: 'USE after deciding which features (capture_photo, transcription_incremental, voice_command, …) the app integrates.' It also provides a clear exclusion: 'DON'T USE for capability discovery (use getPlatformInfo).' This is a model of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it's read-only ('METADATA ONLY'), never returns transcripts or PII, reads from prod-attested telemetry warehouse, and explains auth/ownership checks (403 errors) and setup (401 -> run login). No contradictions.
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 description is a single solid paragraph, dense but not overly long. Key information is front-loaded (what it does, what it returns). Could benefit from bullet points for readability, but still efficient.
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?
No output schema, but the description enumerates the return fields (window, totals, byEvent, etc.), explains data source and emptiness condition, covers error responses (403, 401) and prerequisites, and guides against misuse. Very complete.
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 baseline 3. The description adds meaning beyond schema by explaining the default and range for 'days' (clamped [1,365]), calling 'appPackage' a 'bundle id', and describing the return shape which the schema doesn't cover.
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 clearly states it reads production analytics for a project, specifying the verb 'Read', the resource 'project's PRODUCTION analytics', and the scope 'aggregate telemetry from ... shipped installs'. It distinguishes itself from sibling tools like getEventLog and getGatewayUsage.
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?
Explicitly tells when to use ('report a shipped app's real-world usage/adoption') and when NOT to use ('DON'T USE for gateway spend (use getGatewayUsage) or live dev events (use getEventLog)'), providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It details each action's effect (select fires onClick, navigate moves focus, back emits back gesture) and the downstream flow mirroring real hardware. Error conditions (browser_not_connected) and relationships to other capabilities are also disclosed.
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 description is lengthy but well-structured with bolded action names and a bullet-like layout. It front-loads the core purpose and packs necessary details. Minor redundancy exists, but every sentence serves a purpose.
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?
The description covers prerequisites, typical loop, error conditions, and relationships to other tools. It provides enough context for an agent to use this complex tool correctly without an output schema.
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 description coverage is 67%, and the description adds significant value beyond the schema: it explains where to get targetId values, the effect of omitting it for navigate, and the role of sessionId in the typical loop. However, sessionId itself is not elaborately described.
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 clearly states the tool's purpose: driving simulated glasses display input as an agent's way to 'click' the display. It names three specific actions (select, navigate, back) and distinguishes itself from sibling tools like injectTranscript and setSimVideo.
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 usage guidance is provided: 'USE to exercise display button handlers + navigation end-to-end. DON'T USE for voice flows... or to read display state.' It also gives a prerequisite (call ensureSimulatorBrowser first) and a typical loop, making when-to-use and when-not-to-use very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels. It discloses partial update, validation against catalog, cost impact echo, access gating with default Read+Write, error codes meaning, linked account requirement, and cross-platform session application. No contradictions.
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 description is fairly long but well-structured. First sentence gives purpose and scope, then details validation, cost, gating, errors, platform effects, and usage guidance. Every sentence adds value; could be slightly tighter but efficiently conveys critical information.
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?
Given 5 parameters (4 enums), partial update, validation, cost impact, gated access, error conditions, and cross-platform behavior, the description covers all necessary context for correct invocation. No output schema, but return behavior is sufficiently described (errors, cost echo). Complete for a configuration mutation 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 description coverage is 100% (baseline 3). The description adds value by clarifying that parameters are optional for partial updates, advising to call getAssistantConfig first to see valid ids, and noting cost impact for model change. This goes beyond schema documentation.
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 clearly states it changes dashboard-managed agent settings (voice, realtime model, compaction model, within-session memory) via MCP. It distinguishes from getAssistantConfig (reading) and setCredential (secrets), and specifies partial update behavior. The verb 'Change' and resource 'dashboard-managed Agent settings' are specific and unambiguous.
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?
The description explicitly tells when to use ('USE to configure a project's voice agent from the agent loop') and when not to use ('DON'T USE to read current settings (use getAssistantConfig) or to set secrets'). It also advises calling getAssistantConfig first to see valid ids, and mentions the gated access and error responses (401, 403) with instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral transparency. It discloses that deletion disconnects attached apps/browsers, that apps with baked EXTENTOS_SESSION_URL need rebuilding, that session churn leaves stale device registrations, and that the tool is idempotent returning alreadyGone: true. These are critical behavioral traits beyond the simple 'delete' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical, but every sentence earns its place for a destructive tool. It front-loads the core purpose and then systematically covers usage, warnings, workflow, costs, and idempotency. The structure is logical and dense without redundancy, making the length appropriate.
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?
For a destructive tool with no annotations and no output schema, the description covers all necessary context: preconditions, consequences, workflow position, side effects, and return behavior on already-gone sessions. It explains the persistent-sim model and why one-call force-fresh doesn't exist, giving the agent a complete mental model.
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?
The schema has one required sessionId with no description, and the description does not explicitly explain the parameter. However, the single parameter's meaning is self-evident from the tool name and context; the description reinforces that sessionId identifies the session to retire. Since it is a simple string with minLength, the lack of explicit parameter detail is not a significant gap.
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 'Retire a simulator session on purpose,' providing a specific verb and resource. It clearly distinguishes this tool from createSimulatorSession by stating that delete is only for rotating to a new session identity, and explicitly contrasts the delete-and-mint flow with the resume model.
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?
The description gives explicit when-to-use and when-not-to-use instructions: 'USE only when you genuinely need a NEW session identity' and 'DON'T USE to clean up or start over.' It names the alternative (createSimulatorSession) and explains the intended two-step rotation process, providing unambiguous decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It thoroughly describes the two-call flow, the existing-app detection logic (object + manual_patch vs full Application subclass), the return format (files[] with action values 'create' and 'manual_patch'), and platform-specific dependency differences (Android vs iOS). It also discloses that re-running with updated capabilities regenerates the bootstrap and mentions the 'no clobber' promise.
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 description is long but well-organized with bold section headers and clear separation of concerns. It front-loads the core purpose, then covers usage, platform nuances, and edge cases. While every section earns its place, there is some redundancy (e.g., the emphasis on capabilities-derived path appears twice) and the platform nuance section is quite dense, so a slight tightening could improve conciseness without losing value.
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?
Given the tool's complexity (8 parameters, multiple platforms, two-call flow, existing-app detection) and the absence of an output schema, the description leaves little uncovered. It explains the return value, references searchDocs('file_actions') for handling actions, covers platform-specific behaviors, and handles edge cases like greenfield vs existing app. It is exceptionally complete for a tool of this scope.
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?
The description adds substantial meaning beyond the input schema. It explains how `capabilities` drives the scaffold type (VOICE vs DEVICE) and the derived path, how `placement` is used across calls, and how `projectPath` triggers existing-app detection. It also clarifies that `appPackage` is decoupled from store bundle ids, which is not apparent in the schema.
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 'One-shot project scaffold — emits the bootstrap module that wires `Extentos.create(...)` into the host app', which clearly states the verb, resource, and output. It goes on to detail what is emitted (build-script changes, dependencies, permissions, integration manifest), and distinguishes itself from siblings by explicitly positioning it as the first generation tool and contrasting with inspectIntegration for already-installed projects.
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?
Explicitly states when to use ('USE as the first generation tool when scaffolding a fresh project') and when not to ('DON'T USE when Extentos is already installed'), even naming the alternative tool (inspectIntegration). It also provides detailed instructions on the two-call flow (without and with placement) and gives concrete guidance on how to handle existing apps via projectPath.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so exceptionally. It details the return structure (`{ results, generalGuidance, summary }`), the shape of `results` entries, the list of rules, severity levels (`error` vs `warning`/`info`), and which specific issues are error-level. It also discloses that behavior is identical regardless of the API surface used, adding meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence is dense with essential information. It is front-loaded with the primary purpose, then systematically covers return type, rule details, API applicability, and usage guidance. There is no filler or redundancy; the structure makes it easy to parse despite the length.
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?
The tool returns a complex nested result with no output schema, but the description fully compensates by detailing the entire return structure, including per-phrase issue objects, rule names, and severity semantics. It also covers usage context, exclusions, and alternatives, making the description self-sufficient for an agent to invoke it correctly.
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?
The input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds extra semantic value by explaining how `existingPhrases` influences behavior (flagging exact-duplicate collisions and shared-prefix ambiguity) and by describing the output structure that depends on those parameters. This goes beyond simple schema repetition, justifying a 4.
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 clearly states a specific verb ('Analyze') and resource ('proposed voice phrases'), with a defined goal ('for UX issues') and a list of concrete rules. It distinguishes itself from siblings by explicitly naming `searchDocs` as the alternative for general voice docs, making it clear what this tool is for.
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?
The description gives explicit when-to-use ('USE before adding new phrase-match conditions to ANY voice-driven handler'), when-not-to-use ('DON'T USE for general voice docs'), and points to the alternative tool (`use searchDocs topic 'voice_integration'`). It also clarifies applicability across two API surfaces, leaving no ambiguity about the intended invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully covers behavioral traits. It details the effects of tap vs hold, stream state transitions, error handling, differences from real hardware, and visual cues (LED). This is comprehensive transparency.
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 description is long but well-structured and front-loaded. Every sentence adds value, though some redundancy could be trimmed. However, the detail is justified given the complexity.
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?
The description is complete for a tool with 3 parameters and no output schema. It covers input, behavior, side effects, error handling, and typical usage. No missing context.
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?
The description adds significant meaning beyond the schema. It explains default values for action and button, the complete gesture set, and provides a typical usage loop. Schema coverage is 67%, but the description compensates fully with rich context.
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 clearly states the tool's purpose: pressing the simulated glasses' hardware capture button. It distinguishes this from sibling tools like injectInput and injectTranscript by specifying it's for hardware gestures, not display input or voice.
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 usage guidelines are provided: 'USE to test paused/stopped-camera handling end-to-end. DON'T USE for display input (injectInput), voice (injectTranscript), or hardware alerts.' Also includes a typical loop example, making it very clear when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that `found: false` is not an error, explains the behavior in that case (returns empty sub-objects and a `gaps` remediation string), and details all return fields. It also states read-only nature, leaving no hidden behavior.
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 description is well-structured with a concise opening sentence followed by a detailed breakdown using backticks and bold. It is slightly long but every sentence adds value. Could be slightly tightened, but very effective.
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?
Given no output schema, the description compensates fully by enumerating all return fields and their sub-fields with behavior. It covers all relevant scenarios (found vs not found), making the tool's complete behavior transparent. No detail is missing.
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 100% (projectPath). The description adds meaningful context beyond the schema: explains it's optional, defaults to cwd, and advises when to pass it explicitly. This covers syntax and usage intent.
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 clear verb-resource phrase: 'Read-only snapshot of the current Extentos integration at a project path.' It names the return structure, distinguishes from sibling validateIntegration by providing explicit usage guidance, and leaves no ambiguity about the tool's purpose.
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?
Explicitly states when to use ('USE before validateIntegration or for a 'what's wired so far?' read') and when NOT to use ('DON'T USE for correctness checking / a pre-test gate'), and names the alternative (validateIntegration) with a brief rationale. This provides clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it follows the same hub path as real browser clicks, produces identical handler dispatch and event-log entries, triggers the glasses.voice.onPhrase matcher, and clarifies final vs. partial transcript semantics, giving agents a complete mental model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: starts with the core purpose, then explains the mechanism, usage pattern, exclusions, and adds a pointer to an example—every sentence contributes value without redundancy, making it dense but efficient.
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?
For a tool with 5 parameters, no annotations, and no output schema, the description is comprehensive: it covers when and how to use, what happens during execution (handler dispatch and event-log entries), and how to verify via getEventLog, leaving no critical gaps.
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 80%, but the description adds significant semantic context: it explains the wake-phrase matching behavior, case-insensitive substring matching, the purpose of isFinal/partial for testing live-captions, and the confidence default matching manual_trigger, all of which enrich the schema.
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 clearly states the specific action: injecting a synthetic STT transcript into a live simulator session, and explicitly distinguishes from siblings by contrasting with validateIntegration and getPlatformInfo, as well as referencing related tools like createSimulatorSession and getEventLog.
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?
It provides explicit USE/DON'T USE guidance, specifying when to use injectTranscript (automated voice-flow validation) and when not to (static validation via validateIntegration, capability discovery via getPlatformInfo), plus a reference to getCodeExample for a full recipe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and meets it: it discloses the enforcement rule ('At least one of `topic` or `query` is required... returns an invalid_arguments error'), stable topic IDs, snippets-mode paragraph limits, and the differing behavior when both parameters are supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely packed, with each section earning its place: purpose, topic list, usage conditions, mode semantics, and off-path disambiguation. It is front-loaded with the core function, and the extensive topic enumeration prevents invalid calls by providing valid string constants.
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?
Given no output schema and three mostly optional params, the description covers everything an agent needs: it explains error behavior, mode output shapes, canonical topic IDs, and explicitly contrasts with sibling tools. No critical behavioral aspect is missing.
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?
Although the schema already describes each parameter (100% coverage), the description adds essential semantics: the canonical topic list, the three parameter combination patterns (topic alone, query alone, both), and the snippet mode constraint (requires query). This goes far beyond the schema's field-level descriptions.
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 clear, specific verb+resource: 'Search Extentos documentation by topic or keyword.' It further distinguishes itself from siblings by explicitly naming what it is NOT for ('DON'T USE for the platform capability list (use getPlatformInfo)...'), making its purpose unambiguous.
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?
The description provides explicit USE/DON'T USE guidance with named alternates (getPlatformInfo, getCapabilityGuide, inspectIntegration). It also details when to use full vs snippets mode based on query scope, offering context for both common and edge use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden. It discloses that the tool is a write operation that never accepts the secret, returns a browser handoff for secure entry, and is gated by credentials access grant. It explains the security design and error responses. No contradictions with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is necessary and contributes value. The description is front-loaded with the core purpose, then systematically covers security design, return value, access control, error handling, and usage guidance. No redundancy or wasted words.
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?
The description is fully complete for the tool's complexity: it explains what the tool does, how to use it, the return format, access gating, error codes, and the recommended post-step. Despite no output schema, the return shape is explicitly given. No gaps remain for an agent to misuse it.
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 100%, but the description adds significant context: appPackage is described as "The app's package / bundle id (project_install_id)", and credentialType explains why only meta_dat exists ("the assistant runs on the Extentos managed gateway and there is no provider key to supply"). This enriches the schema definitions.
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 clearly states the verb "Start WRITE-WITHOUT-KNOWING entry" and the resource "Meta DAT build identity", distinguishing it from siblings like getCredentialStatus which confirms the credential. It emphasizes the unique design of not passing the secret.
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?
Explicitly guides when to use: "USE to wire up a project's API key from the agent loop without ever handling the secret." Provides clear exclusions: "DON'T pass a key value (there is no field for it) and DON'T ask the developer to paste a secret into the chat." Suggests follow-up with getCredentialStatus. Also explains error scenarios (403, 401).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/extentos/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/extentos/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/extentos/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/extentos/mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/extentos/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server