Retired identity. TrustyCap is published as com.trustycap/trustycap. Install that.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 13 tools
The tools are organized around distinct phases (discovery, readiness, routing, composition, workspace), and descriptions explicitly cross-reference when to use one over another. However, compose_kit, guide, route_build, and start_workspace all occupy a similar 'what should I build/install' space requiring careful reading to pick correctly.
All names share the trustycap_ prefix and lowercase snake_case, so the set looks uniform at a glance, but the suffixes mix verb_noun forms (list_capabilities, compose_kit, start_workspace) with noun-only forms (guide, native_readiness, production_plan, production_standard). This split makes the naming pattern only partially predictable.
Thirteen tools is within a reasonable range for a platform covering capabilities, launch kits, native kits, production readiness, and workspace setup. The count is justified, though a few readiness/plan/standard tools are close in function and could arguably be consolidated.
The set covers the full journey from discovery (list/guide), through fit assessment and readiness scanning, to routing, kit selection, and starting a workspace with a claim URL. Minor gaps exist around post-workspace lifecycle (status, updates, deletion), but those appear intentionally handled outside the MCP surface.
Use this when what your human is building is not one of the published Launch Kits. Say what the business has to do, in their words, and get back a kit composed from real capabilities with real prices and a real install path, plus a list of what was left out and why. Pass their creation platform and it will refuse to compose anything that platform already supplies. Pass capability ids instead of a sentence to compose exactly what you picked. It never invents a unit price for a business nobody has priced; it prices each meter and leaves the arithmetic where your human can see it.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | What the business has to do, in your human's own words. | |
| platform | No | The creation platform their application came from. | |
| capabilities | No | Capability ids or aliases to compose exactly, instead of matching on the sentence. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, but the description adds genuinely new traits: it refuses to compose anything the supplied platform already provides, it will not invent a unit price, it prices each meter, and it returns what was left out and why. That is rich, non-obvious behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the usage condition, then proceeds to behavior and pricing. Four dense sentences with no filler, though the pricing sentence is information-packed enough that it could be split for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the burden of describing returns, which it does: a composed kit with real prices and an install path, plus a list of exclusions and reasons. Completeness is strong, with only minor gaps around output format specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: 'platform' triggers a refusal behavior, and 'capabilities' is an alternative to 'intent' for composing exact picks. This clarifies the interaction between parameters rather than restating them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compose) and resource (kit) scoped to 'a business nobody has composed,' which cleanly separates it from the published Launch Kit siblings like trustycap_get_launch_kit. An agent can identify the operation and its niche without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('when what your human is building is not one of the published Launch Kits') and by implication routes published-kit cases to trustycap_get_launch_kit. It also clarifies the two invocation modes: a natural-language sentence versus capability ids to compose exactly what was picked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this before writing or changing code against a kit. The full starting point for one Launch Kit: the step-by-step workflow with the capability each step calls, which steps stop for a human, what one unit of the builder's business costs at list price, the production checklist, and the customization contract. Read this before writing or changing code against a kit. The contract classifies every surface as customizable, extensible, required, platform_managed or protected, so you can transform the kit into a materially different product (new name, brand, audience, pricing, screens, workflow, capability mix) without touching the authorization, metering, proof or payment-authority boundaries that make the result trustworthy.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Launch Kit id, e.g. vehicle-finance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the returned content (workflow, costs, contract) and the contract's surface classification, but it doesn't disclose any additional behavioral traits like response size, pagination, or error behavior. Given the annotations, a 3 is appropriate – it adds some value but not beyond what is already known.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but contains redundancy: the sentence 'Read this before writing or changing code against a kit.' repeats the opening instruction 'Use this before writing or changing code against a kit.' This duplication wastes space. The rest is structured logically, but the repetition and verbosity prevent a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and lack of an output schema, the description is comprehensive. It details what the tool returns (workflow, costs, checklist, contract) and explains the contract's classifications, which helps an agent understand the full value. It lacks only minor details like error handling, but for a read-only retrieval tool, this is adequate. A 4 reflects the thoroughness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'id' is fully described in the schema with an example ('vehicle-finance'), achieving 100% schema coverage. The description does not add any extra meaning about the parameter beyond the schema. Per the baseline rule for high schema coverage, a 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a complete Launch Kit, enumerating its contents (workflow, costs, checklist, contract). It differentiates from list_launch_kits by focusing on a single kit's full details, not a listing. The verb 'get' and resource 'Launch Kit' 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this before writing or changing code against a kit' and repeats the guidance, giving a clear when-to-use context. It doesn't name alternative tools or exclusions, but the sibling list includes list_launch_kits, implying a distinction. The guidance is practical and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this before touching a native project, once a kit has been chosen. Everything needed to install one Native Kit without reverse-engineering the application it came from: every file it ships with its content hash and the production path it was cut from, every pinned dependency and why that pin, every permission, entitlement, background mode and plist or manifest key with what breaks when it is absent, the JavaScript interface, the configuration that must not be changed and the reason for each, the ordered install steps including the ones that need a human in Xcode or a provider console, what is proven and how, and the real constraints. Read this before touching a native project.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Native Kit id, e.g. background-location |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns a comprehensive bundle of files, hashes, dependencies, permissions, install steps, and constraints. It also warns that some install steps need a human in Xcode or a provider console, which is a real behavioral constraint beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, and it front-loads the critical usage instruction ('Use this before touching a native project'). Every clause adds a distinct piece of information about what the kit includes. It is somewhat verbose, but the density justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with one parameter and no output schema, the description is remarkably complete. It tells the agent what the returned kit contains, what to do before calling, and what constraints to expect. The only minor gap is not describing the exact output format, but the description's enumeration of contents compensates for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter 'id' is described with an example ('e.g. background-location'). The description doesn't add much about the parameter itself, but with full schema coverage and a single simple parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and resource ('a TrustyCap Native Kit'), and immediately distinguishes it from siblings by saying 'Use this before touching a native project, once a kit has been chosen.' It also contrasts with reverse-engineering, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('before touching a native project, once a kit has been chosen') and implies when not to use it (before a kit is chosen, presumably use list_native_kits or guide). It also names the alternative behavior (reverse-engineering) that this tool avoids, giving clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone says what they want rather than which capability they want. Say what the human is trying to build, in their words, and get back the Launch Kits and capabilities that actually fit, why each one matched, what one unit of that business costs at published prices, and a build plan you can act on. Use this when someone says what they want rather than which capability they want. Deterministic: it answers only from the published registry and rate card, so it cannot invent a capability, a kit or a price.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | What the builder said they want to build, in their own words. | |
| launch_kit | No | Optional. A Launch Kit id to plan against directly, skipping the recommendation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true. The description goes beyond these by adding deterministic behavior: 'it answers only from the published registry and rate card, so it cannot invent a capability, a kit or a price.' It also reveals what the response contains (matching reasons, costs, build plan). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is mostly concise, but the sentence 'Use this when someone says what they want rather than which capability they want' appears twice verbatim, wasting a sentence. The first sentence is front-loaded and effective, but the duplication is a clear structural flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the trigger condition, the outputs, and the deterministic grounding, which gives an agent enough to decide when to invoke the tool. There is no output schema to lean on, so listing the response components (Launch Kits, capabilities, why matched, cost, build plan) is valuable. It could mention what happens with the optional launch_kit parameter, but that is a secondary gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds slight nuance for the intent parameter ('in their words') but says nothing about the optional launch_kit parameter beyond the schema. It does not actively mislead, but it also does not enrich the parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific use case: 'Use this when someone says what they want rather than which capability they want.' It names the exact resource (Launch Kits and capabilities) and the outputs (matched items, why each matched, unit cost, build plan). This clearly distinguishes it from sibling tools like trustycap_get_launch_kit or 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this when someone says what they want rather than which capability they want.' It gives a clear condition and implies that other tools are for when a specific capability is known, but it does not name alternatives or list exclusions. The repetition of the same sentence adds no new guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person needs one specific thing rather than a whole backend: somewhere to put files, records that survive a restart, work that runs in the background or on a schedule, webhooks that are not lost when a handler fails, credentials out of the code, email that arrives, a document read into structured data, money held until delivery is proven, an insurance claim checked before it goes out, or a vehicle, loan or property fact resolved. Returns every public capability: what it is for, when to choose it, what it will not do, the scopes a key needs, the meters it charges and the published price of each. Call this before assuming a capability exists. Do not use it to choose a whole stack: call trustycap_list_launch_kits when the person is describing a business rather than an operation.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Optional family filter. Accepts the neutral name (vehicle, financing, documents, transactions, digital-life, exit-paths, finance-math) or the canonical id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so the description doesn't need to restate safety. It adds value by disclosing what the output contains (purpose, constraints, scopes, meters, price), which is essential given the absence of an output schema. It also frames the tool as a pre-check before assuming capabilities exist, offering behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: it front-loads the use case, lists illustrative examples, then describes the return, and ends with a clear exclusion. Every sentence contributes to guiding the agent, though the long list of examples could be condensed. It earns a 4 for good organization and purpose-packed content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain return values, and it does thoroughly: what each capability entry includes and how to interpret it. It also covers the family filter implicitly through schema and provides clear usage boundaries. The description is complete for the tool's complexity and lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter 'family' is clearly documented in the schema. The tool description does not mention the parameter, but with full schema coverage the baseline is 3. No additional meaning is added, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns every public capability' and specifies exactly what that includes (purpose, when to choose, what it won't do, scopes, meters, price). It distinguishes itself from siblings by explicitly naming trustycap_list_launch_kits as the alternative for choosing a whole stack, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit 'When to use' guidance with concrete examples (files, records, background work, webhooks, etc.), states 'Call this before assuming a capability exists,' and provides a clear exclusion: 'Do not use it to choose a whole stack: call trustycap_list_launch_kits.' This fully covers when 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.
Use this when someone describes a business they want to build rather than a single operation they want performed, and needs a whole backend rather than one piece: proven compositions a builder can start a business from. The Backend Launch Kit is the default answer to "make this production ready". Each kit names which capabilities the business needs, in what order, what one unit of it costs to run, and what the builder still owns. Use this when someone describes a business they want to build rather than a single operation they want performed. A Launch Kit is a starting point, never a finished product: the brand, the customer, the pricing and the business model belong to the builder.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful output-adjacent context: each kit names required capabilities, their order, cost per unit, and what the builder owns. It also clarifies product boundaries by stating the brand, customer, pricing, and business model remain the builder's responsibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a strong usage signal, but it repeats the sentence 'Use this when someone describes a business they want to build rather than a single operation they want performed' twice verbatim. That redundancy wastes space and detracts from an otherwise focused description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description is complete: it says when to invoke it, what a Launch Kit is, what information each kit conveys, and what it does not provide. An agent has enough to select and call the tool correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema carries no burden. The description appropriately spends no space on parameter details and instead explains the content of the returned launching kits, which is the only meaningful semantic information an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's scope: listing proven backend compositions for someone building a whole business, not performing a single operation. It explicitly contrasts with operation-level tools and signals the resource type (Launch Kits) and what makes them distinct from one-off tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear condition: use when a user describes a business to build and needs a whole backend. It also states that a Launch Kit is a starting point, not a finished product, which helps set expectations. It doesn't explicitly name alternatives like native kits or capabilities, but the 'rather than a single operation' phrasing effectively excludes them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person needs their app in the App Store or Play Store, or when the problem is on the device rather than on the server. 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to state safety. It adds useful context about licensing ('licensed per production application and free in test mode') and that kits are 'already finished,' but it does not disclose what the output of the list operation actually looks like, especially given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is considerably overlong and repetitive, repeating 'Use this when the problem is on the device rather than on the server' and enumerating a long list of examples. It contains useful details about Native Kits, but far more sentences than needed for a 0-parameter list tool, indicating under-specification rather than controlled brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently differentiates Native Kits from capabilities and gives licensing/scoping details, but with no output schema it does not explicitly say that the tool returns a list of available kits or what fields accompany each kit. An agent can infer the listing behavior from the title, but the description misses an opportunity to state the return value and relationship with getting a specific kit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the empty input schema is fully self-explanatory. Baseline 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description indicate a listing tool for packaged iOS/Android Native Kits, and the description contrasts it with TrustyCap capabilities ('A capability is something TrustyCap performs when you ask; a Native Kit is packaged...'). However, the description never literally says 'returns a list of available Native Kits,' so the exact listing behavior must be inferred from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear when to use it: 'when the person needs their app in the App Store or Play Store, or when the problem is on the device rather than on the server.' It also implicitly excludes server-side problems and distinguishes capabilities from kits, though it does not name sibling tools like trustycap_get_native_kit explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when your human wants their application in the App Store or Google Play. Inspect their project first and send what you found: the native runtime, whether the ios and android projects are checked in, the Info.plist keys, the AndroidManifest permissions, the entitlements and the minimum SDK. npx @trustycap/cli native reads all of that for you. Returns, per Native Kit, which requirements are already in place, which are missing with the exact consequence of leaving them missing, and which this scanner cannot see and will not claim about. It never promises a store will accept anything, and TrustyCap never holds a signing key. If their creation platform submits to the stores itself, it says so and offers nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| ios | No | Whether an ios/ directory is checked in. | |
| kits | No | Specific Native Kit ids, instead of matching on the sentence. | |
| intent | No | What the app has to do on the phone, in your human's words. | |
| android | No | Whether an android/ directory is checked in. | |
| min_sdk | No | ||
| runtime | Yes | capacitor, expo, react-native, or none. | |
| platform | No | The creation platform their application came from. | |
| entitlements | No | ||
| info_plist_keys | No | ||
| android_manifest_keys | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, read-only, idempotent, closed-world operation, but the description adds substantial behavioral context beyond them: it discloses the return shape (per-Kit in place / missing-with-consequence / not-visible), explicitly bounds what the scanner will not assert ('cannot see and will not claim about'), and states what the tool refuses to promise (store acceptance, signing keys). This is exactly the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Usage is front-loaded in the first sentence and the key disclaimer about not promising store acceptance lands near the end where it matters. It runs long across several clauses, but each sentence carries a distinct idea (how to gather inputs, what is returned, what is disclaimed) rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description steps in to describe the return payload (per-Kit status and consequences), which is the main thing an agent needs. For a 10-parameter tool, two parameters (kits, intent) are left with no guidance in either schema or description, a minor gap but not a blocking one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, and the description largely restates the same fields the schema already documents (runtime, ios, android, Info.plist keys, manifest, entitlements, min SDK) rather than adding syntax or format meaning. The one genuine addition is the instruction to inspect the project before sending, but 'kits' and 'intent' remain unexplained in both places. Baseline 3 is appropriate given the schema does most of the lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: inspect a project's native configuration (runtime, ios/android checked-in, Info.plist keys, AndroidManifest permissions, entitlements, min SDK) and report per Native Kit what is in place vs missing. It is distinguishable from siblings like trustycap_get_native_kit, though it never names which sibling to use instead. The purpose is clear but buried behind the usage sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('when your human wants their application in the App Store or Google Play') and an explicit when-not ('if their creation platform submits to the stores itself, it says so and offers nothing'). It does not name the closest alternative, trustycap_production_readiness, leaving the boundary between the two readiness tools to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you are holding a finding from npx @trustycap/cli productionize and need to fix it. Given its requirement id and classification, returns where the project stands, which implementations would satisfy the requirement with their status (never inventing a failure for one the scanner did not see), the TrustyCap remediation and the exact commands to run and verify, and when TrustyCap should be declined. No credential needed.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | The provider the scanner recognized, if any | |
| requirement | Yes | The finding's requirement id, e.g. TC-PROD-0041 | |
| classification | Yes | The finding's classification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds value beyond annotations by stating 'No credential needed' (auth requirement) and 'never inventing a failure for one the scanner did not see' (reliability guarantee). These are behavioral details not present in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the trigger phrase and then enumerates the outputs. It is a single, long sentence but each clause adds substantive information. It could be split into clearer sentences, but it remains readable and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description thoroughly explains both inputs and outputs: it lists the output components (current state, implementations, remediation, commands, decline scenarios) and notes the credential requirement. Minor gaps include error handling or specific edge cases, but these are not critical for an agent to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The description references 'requirement id' and 'classification' but does not add additional nuance beyond the schema. The optional 'provider' parameter is not mentioned, but the schema already documents it. The description does not compensate for any gaps given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: planning a fix for a production finding from the TrustyCap CLI. It clearly distinguishes itself from siblings by focusing on the remediation pathway rather than discovery or listing. The title and description together convey the exact resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description opens with an explicit trigger: 'Use this when you are holding a finding from... and need to fix it.' This provides clear context for when to invoke the tool. However, it does not mention alternative tools or explicitly state when not to use it, so it lacks the full when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a human asks you to make an application production ready, give it a real backend, get it ready for real customers, or turn something they built on a creation platform into a real business. Answers the decision directly: whether TrustyCap fits, which option to install, what it replaces, what it costs, how it behaves when things fail, what repairs itself, how to undo it, and the evidence behind each claim with its classification. Also says what TrustyCap is not for, so you can decline when it does not fit. No credential needed; call this before installing anything. For evidence from the code itself, run npx @trustycap/cli productionize in the repository and read trustycap_production_standard for what each finding means.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds that no credential is needed and that it should be called before installing anything, which is useful behavioral context beyond the annotations. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence but front-loads the trigger condition and then lists the comprehensive set of answers it provides. Every element contributes to the tool's purpose, and it is not verbose or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-arg decision-support tool, the description fully covers what it does, when to use it, what it answers, and even points to a CLI command for deeper evidence. It also mentions its limitations ('what it is not for'). Nothing an agent needs to decide whether to call this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description need not explain any. The baseline for a 0-parameter tool is 4, and the description adds no unnecessary parameter details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: it is used to make an app production ready and answers the decision directly. It enumerates the exact outputs (whether TrustyCap fits, which option to install, costs, failure behavior, repairs, undo, evidence) and clearly distinguishes itself from siblings by instructing to call it 'before installing anything'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('when a human asks you to make an application production ready...') and provides a precondition ('No credential needed; call this before installing anything'). It also mentions it says what TrustyCap is not for, enabling declination. It doesn't explicitly name sibling alternatives, but the 'call before installing' guidance implies it is the entry point, which is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need to know what a production finding means, or what production actually requires of an AI-built application. The provider-neutral requirements an application is scanned against, each joined to the TrustyCap capability that is its reference implementation. Use it to understand a finding id such as TC-PROD-0041 from npx @trustycap/cli productionize, to see which properties a requirement demands, which other implementations satisfy it, and the exact commands that remediate and verify it. Pass a requirement id to read one, or nothing to read all. No credential needed.
| Name | Required | Description | Default |
|---|---|---|---|
| requirement | No | A requirement id, e.g. TC-PROD-0041. Omit for the whole standard. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavior: passing a requirement id returns one item, omitting it returns all, no credential is needed, and results include properties, alternative implementations, and remediation/verification commands. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary use case and then compactly explains scope, behavior, and invocation. It is dense but not bloated; every sentence contributes useful information. A slightly tighter structure would be possible, but the current form remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple optional-parameter schema, rich annotations, and lack of an output schema, the description provides enough context for correct invocation: what the tool reads, how to select a single requirement, that credentials are unnecessary, and what kinds of information are returned. It does not describe the exact response shape, but that is a minor gap for this read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single optional 'requirement' parameter with an example, achieving 100% coverage. The description adds practical semantics by clarifying that omission reads the entire standard and that the parameter selects a single finding, which helps an agent decide how to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (the provider-neutral production requirements standard), a clear verb context ('know what a production finding means'), and gives a concrete example like TC-PROD-0041 from the productionize CLI. It clearly differentiates this from other capability-exploration tools by focusing on the standard itself and its remediation commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use this when you need to know what a production finding means, or what production actually requires') and how to tailor the call. It does not explicitly mention when not to use it or name sibling alternatives, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when your human already has a working application and wants it to operate as a real business. Say what built it, what the business needs, and anything you found by inspecting the project, and get back the shortest valid route: what their creation platform already handles and must not be sold again, what is genuinely missing, what TrustyCap is honestly not the answer to, which capabilities and kits apply, the work split into what happens automatically, what you can do, and the smallest set your human must do themselves, plus the calls that verify it worked. Deterministic and credential free. Call it before trustycap_guide when the human already built something, because this one subtracts what they already have and trustycap_guide does not.
| Name | Required | Description | Default |
|---|---|---|---|
| has | No | Concerns the project already answers, from your own inspection. Use the concern ids from GET /v1/platforms. | |
| intent | No | What the business needs, in your human's own words. | |
| findings | No | Requirement ids the production scan reported as not passing, e.g. TC-PROD-0041. Run `npx @trustycap/cli productionize` to get them. | |
| platform | No | The creation platform their application came from: lovable, replit, base44, bolt, v0, claude_code, codex, cursor, windsurf, own_code. | |
| framework | No | The framework you detected, if any. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds behavioral context beyond that — 'Deterministic and credential free' — which tells the agent the call is cheap, repeatable, and needs no auth setup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The when-to-use clause is correctly front-loaded, but the body is a single sprawling sentence enumerating nine output items, making it dense and hard to scan. The content is largely non-redundant, but the structure works against quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining returns — which it does in detail, covering subtraction of existing capabilities, gaps, task split, and verification calls. Inputs are fully documented in the schema, so the definition is close to complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description loosely maps to the parameters ('say what built it' → platform/framework, 'what the business needs' → intent, 'anything you found by inspecting the project' → has/findings), which adds some framing, but it never names or disambiguates any parameter and omits `framework` entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete transformation ('route an existing build to production') and enumerates what the return contains — shortest valid route, what the platform already handles, what's missing, capabilities/kits, task split, verification calls. The verb/resource pair is identifiable, though the purpose is delivered through a long value-prop sentence rather than a crisp statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('when your human already has a working application') and names the alternative with a discriminating condition: 'Call it before trustycap_guide when the human already built something, because this one subtracts what they already have and trustycap_guide does not.' It lacks an explicit when-not branch for greenfield, but the condition implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this the moment you decide TrustyCap fits and before you write any code against it. Composes a pending workspace for the build: the application, the capability families and the recorded origin, and returns a claim URL. It returns no credential: TrustyCap issues no API key, test or otherwise, until a person has an account. Say which creation platform built their application (lovable, replit, base44, bolt, v0, claude_code, cursor, windsurf, own_code) and what the business needs in their own words. You can keep planning, routing and composing with no credential at all. When you have something worth showing, send your human the claim URL. Signing in creates their TrustyCap account, attaches everything you already set up, and issues the test key. That is the one step you cannot do for them.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | What your human calls the thing they built. | |
| intent | No | What the business needs, in your human's own words. Never their source code. | |
| platform | No | The creation platform their application came from. One of: lovable, replit, base44, bolt, v0, claude_code, codex, cursor, windsurf, own_code. Omit if you genuinely do not know; do not guess. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only declaring readOnlyHint=false, destructiveHint=false, etc., the description carries the behavioral burden and delivers: it discloses that the tool returns no credential, issues no API key until an account exists, and that signing in is 'the one step you cannot do for them.' This adds meaningful side-effect and auth-flow context beyond the structured fields, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger condition is front-loaded, and each sentence earns its place by explaining the no-credential workflow and the claim URL handoff. It runs slightly long but the length is justified given the unusual no-credential auth flow it must explain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and no output schema, the description covers the trigger, the side effects, the return value (claim URL), the auth limitation, and how to populate intent and platform. The only gap is the platform-enum discrepancy, which slightly detracts from completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some value by instructing to say the platform and the business needs in the human's own words, reinforcing the intent and platform parameters. However, it lists the platform enum without 'codex' (which appears in the schema), creating a minor inconsistency between the description and the schema's parameter definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Composes a pending workspace'), the resource (the build's application, capability families, origin), and the concrete output (a claim URL). It distinguishes itself from siblings like trustycap_route_build and trustycap_compose_kit by anchoring to a specific trigger: 'the moment you decide TrustyCap fits and before you write any code against it.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening sentence gives explicit when-to-use guidance ('Use this the moment you decide TrustyCap fits and before you write any code against it') and clarifies that planning, routing and composing can proceed without a credential. It doesn't explicitly name alternatives or when-not-to-use, but the timing condition is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
trustycap_compose_kittrustycap_native_readinesstrustycap_route_buildtrustycap_start_workspacetrustycap_production_plantrustycap_production_standardtrustycap_get_launch_kittrustycap_get_native_kittrustycap_guidetrustycap_list_capabilitiestrustycap_list_launch_kitstrustycap_list_native_kitstrustycap_production_readinessRetired. Use com.stratalize/stratalize.
Retired. Use com.stratalize/stratalize.
Add one secure layer between your agents and this server.