Skip to main content
Glama

TrustyCap

by com.trustycap

List TrustyCap Native Kits

trustycap_list_native_kits
Read-onlyIdempotent

Native work that is already finished. A capability is something TrustyCap performs when you ask; a Native Kit is packaged iOS and Android source with the exact dependency pins, permissions, entitlements, plist keys and protected configuration that make it work, cut from TrustyCap products where it runs in production. Use this when the problem is on the device rather than on the server: background location that survives a locked phone, native sign-in, store billing, secure storage, share-sheet intake, push tokens, safe-area insets, saving a generated document from a WebView. Kits are licensed per production application and free in test mode and development builds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds valuable context: kits are 'cut from TrustyCap products where it runs in production' and 'licensed per production application and free in test mode and development builds.' This goes beyond the structured annotations without contradicting them.

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 longer than strictly necessary but every sentence earns its place: scope, definition, usage, and licensing. It front-loads 'Native work that is already finished' before expanding into context. Slightly verbose but well-organized.

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?

For a 0-parameter, read-only list tool with no output schema, the description covers what the tool lists, when to use it, and licensing implications. It doesn't explicitly describe the response format, but the title and sibling tools make the list semantics inferable.

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 tool has zero parameters and the input schema is empty, so the baseline is 4. The description adds no parameter-specific meaning, but none is needed. The schema fully covers the absent parameters.

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 title 'List TrustyCap Native Kits' plus the description 'Native work that is already finished' clearly identifies the verb (list) and resource (Native Kits). It also distinguishes Native Kits from capabilities ('A capability is something TrustyCap performs when you ask; a Native Kit is packaged iOS and Android source...'), so an agent can tell it apart from sibling tools like trustycap_list_capabilities.

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

Usage Guidelines4/5

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

The description gives explicit usage guidance: 'Use this when the problem is on the device rather than on the server' followed by concrete device-side examples. It does not name an alternative tool directly, but the capability-vs-kit contrast implies when the other listing tool might apply.

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

All TrustyCap toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Each tool targets a distinct resource or decision point—capabilities, launch kits, native kits, and production readiness—but trustycap_guide and trustycap_production_readiness can both respond to a human asking what to build, and guide overlaps somewhat with the list_* tools in matching outcomes. The detailed descriptions resolve most ambiguity, so the set is largely clear.

Naming Consistency4/5

Most tools follow a trustycap_<verb>_<noun> pattern, such as list_capabilities, get_launch_kit, and list_native_kits. trustycap_guide and trustycap_production_readiness break that convention with a bare verb and a noun phrase, but the shared prefix and snake_case style keep the naming mostly predictable.

Tool Count5/5

Seven tools is well-scoped for a reference and decisioning server covering three resource families plus guidance. Each tool has a clear purpose, and there are no redundant entries.

Completeness4/5

The surface covers listing and retrieving Launch Kits and Native Kits, enumerating capabilities, guided matching, and production-readiness evaluation. Minor gaps exist—such as no separate capability-detail tool and no tool to execute or install a kit—but those seem outside the server's informational scope.

Resources