Skip to main content
Glama

Get Integration Kit

boosthis_get_integration_kit
Read-only

A Boosthis kit for THIS project - no upload; the single-use address needs no key, include_files no shell. Withheld reply? Same kit at GET https://www.boosthis.com/api/kit/ (project key as bearer). runtime picks the kit; see its enum. The reply carries file_list (path + sha256), version and kit_download_once_url (install_command adds typed commands). One kit per runtime, same key. Writing the files is not the install: the kit is wired in, reporting switched on, and the app confirmed checked in.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runtimeNoRequired. Which runtime kit to deliver. Boosthis names every runtime a project spans at https://www.boosthis.com/scan.
runtimesNoOptional. Several runtimes in one call, for a project with more than one surface. The reply is one download address per runtime, not one kit's files.
files_pageNoPage of the by-value walk: guide parts first, then files. Defaults to 1; files_next_page names the next while any remain.
project_codeNoThe 8-character project code from this description's lead - not the name, which two projects can share. Needed only with an account token.
include_filesNoSend every kit file by value instead of the manifest, a page at a time. Needed only when a shell command cannot be run.
install_commandNoAdds the typed download commands to the reply.

Schema Changelog

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

  1. Changed3 schema fields changed
    • changedInput schema / properties / project_code / description
      Previous value: -"The 8-character project code from this description's lead - not the name, which two projects can share. Only a caller using an account token needs it."New value: +"The 8-character project code from this description's lead - not the name, which two projects can share. Needed only with an account token."
    • changedInput schema / properties / runtimes / description
      Previous value: -"Optional. Several runtimes in one call, for a project with more than one surface. The reply is one download address per runtime rather than one kit's files."New value: +"Optional. Several runtimes in one call, for a project with more than one surface. The reply is one download address per runtime, not one kit's files."
    • removedInput schema / properties / runtimes / items / enum
      Removed value: -[
      -  "rn",
      -  "web",
      -  "node",
      -  "bun",
      -  "python",
      -  "java",
      -  "go",
      -  "php",
      -  "dotnet",
      -  "ruby",
      -  "flutter",
      -  "swift",
      -  "kotlin",
      -  "rust",
      -  "elixir",
      -  "edge"
      -]
  2. Changed1 schema field changed
    • changedInput schema / properties / project_code / description
      Previous value: -"The 8-character project code from this description's lead - not the name, which two projects can share. Needed only by a caller using an account token, which names no project of its own."New value: +"The 8-character project code from this description's lead - not the name, which two projects can share. Only a caller using an account token needs it."
  3. Changed5 schema fields changed
    • changedInput schema / properties / files_page / description
      Previous value: -"Page of files[] when include_files is true. Defaults to 1; the reply carries files_next_page while more remain."New value: +"Page of the by-value walk: guide parts first, then files. Defaults to 1; files_next_page names the next while any remain."
    • removedInput schema / properties / include_guide
      Removed value: -{
      -  "description": "Add the written install guide. Left out by default: it is most of the reply's size. The kit address above serves it.",
      -  "type": "boolean"
      -}
    • changedInput schema / properties / project_code / description
      Previous value: -"The 8-character project code from this description's lead — not the name, which two projects can share. Required if the account holds several projects."New value: +"The 8-character project code from this description's lead - not the name, which two projects can share. Needed only by a caller using an account token, which names no project of its own."
    • changedInput schema / properties / runtime / description
      Previous value: -"Which runtime kit to deliver. Defaults to 'rn'. Boosthis names every runtime a project spans at https://www.boosthis.com/scan."New value: +"Required. Which runtime kit to deliver. Boosthis names every runtime a project spans at https://www.boosthis.com/scan."
    • addedInput schema / properties / runtimes
      Added value: +{
      +  "description": "Optional. Several runtimes in one call, for a project with more than one surface. The reply is one download address per runtime rather than one kit's files.",
      +  "items": {
      +    "enum": [
      +      "rn",
      +      "web",
      +      "node",
      +      "bun",
      +      "python",
      +      "java",
      +      "go",
      +      "php",
      +      "dotnet",
      +      "ruby",
      +      "flutter",
      +      "swift",
      +      "kotlin",
      +      "rust",
      +      "elixir",
      +      "edge"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  4. Changed5 schema fields changed
    • changedInput schema / properties / files_page / description
      Previous value: -"Which page of files[] to send when include_files is true. Defaults to 1; keep calling with the next page while the reply carries files_next_page."New value: +"Page of files[] when include_files is true. Defaults to 1; the reply carries files_next_page while more remain."
    • changedInput schema / properties / include_files / description
      Previous value: -"Send every kit file by value instead of the compact manifest. Needed only when a shell command cannot be run — the files then arrive a page at a time. The largest reply this tool produces, so the guide is added only if include_guide asks too."New value: +"Send every kit file by value instead of the manifest, a page at a time. Needed only when a shell command cannot be run."
    • changedInput schema / properties / include_guide / description
      Previous value: -"Add the full written install guide to the reply. Left out by default: it is most of the reply's size and hosts withhold replies that large. The kit address above serves it too."New value: +"Add the written install guide. Left out by default: it is most of the reply's size. The kit address above serves it."
    • changedInput schema / properties / project_code / description
      Previous value: -"The 8-character project code from this description's lead — not the project name, which two projects can share. Required when the account holds several projects."New value: +"The 8-character project code from this description's lead — not the name, which two projects can share. Required if the account holds several projects."
    • changedInput schema / properties / runtime / description
      Previous value: -"Which runtime kit to deliver, matched to the project you are in. Defaults to 'rn' (React Native) when omitted. Boosthis names every runtime a project spans at https://www.boosthis.com/scan."New value: +"Which runtime kit to deliver. Defaults to 'rn'. Boosthis names every runtime a project spans at https://www.boosthis.com/scan."
  5. Changed1 schema field changed
    • changedInput schema / properties / runtime / description
      Previous value: -"Which runtime kit to deliver, matched to the project you are in. Defaults to 'rn' (React Native) when omitted."New value: +"Which runtime kit to deliver, matched to the project you are in. Defaults to 'rn' (React Native) when omitted. Boosthis names every runtime a project spans at https://www.boosthis.com/scan."
  6. Changed3 schema fields changed
    • changedInput schema / properties / include_files / description
      Previous value: -"Send every kit file by value instead of the compact manifest. Needed only when a shell command cannot be run — the files then arrive a page at a time. This is the largest reply this tool produces, so the guide is not added unless include_guide asks for it too."New value: +"Send every kit file by value instead of the compact manifest. Needed only when a shell command cannot be run — the files then arrive a page at a time. The largest reply this tool produces, so the guide is added only if include_guide asks too."
    • changedInput schema / properties / include_guide / description
      Previous value: -"Add the full written install guide to the reply. It is left out by default because it is most of the reply's size and hosts withhold replies that large; the same text is also served at the plain-HTTPS kit address."New value: +"Add the full written install guide to the reply. Left out by default: it is most of the reply's size and hosts withhold replies that large. The kit address above serves it too."
    • changedInput schema / properties / project_code / description
      Previous value: -"Confirms which project this install belongs to. The exact project code or project name is accepted, case-insensitively."New value: +"The 8-character project code from this description's lead — not the project name, which two projects can share. Required when the account holds several projects."
  7. Changed1 schema field changed
    • addedInput schema / properties / install_command
      Added value: +{
      +  "description": "Adds the typed download commands to the reply.",
      +  "type": "boolean"
      +}
  8. First observed

TDQS

A3.8/5.0
Behavior5/5

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

With readOnlyHint=true and destructiveHint=false, the safety profile is already declared, so the bar is lower; the description clears it easily. It adds non-obvious behavior: no upload, a key-less single-use address, a bearer-token fallback endpoint, the exact response payload (file_list with path+sha256, version, kit_download_once_url), and a critical semantic clarification that writing files is not the install (wiring, reporting, and checked-in confirmation). This is valuable contextual disclosure well 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is economically short — six sentences with high information density — and the core purpose is front-loaded. However, the telegraphic phrasing hurts: 'Withheld reply?', 'include_files no shell', and 'same key' are cryptic fragments that demand inference or prior domain knowledge. It is compressed, not genuinely clear.

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 six parameters, no output schema, and read-only annotations, the description covers a lot: purpose, no-upload constraint, auth fallback, return payload shape, and the install-vs-write distinction. It compensates well for the absent output schema. Remaining gaps are minor: how 'THIS project' is bound, what 'typed commands' concretely are, and how the flow ties into verify_kit_install.

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 description coverage is 100%, so the baseline is 3. The description reinforces relationships among parameters ('runtime picks the kit', 'install_command adds typed commands', 'include_files no shell') but adds no meaning that the schema's own rich parameter descriptions lack. It usefully weaves parameters into the overall flow without compensating for any coverage gap, since none exists.

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

Purpose4/5

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

The opening sentence names the deliverable ('A Boosthis kit for THIS project') and immediately distinguishes it from an upload flow ('no upload'), while 'runtime picks the kit; see its enum' and 'One kit per runtime' specify the selection model. It differentiates from siblings like get_removal_kit by scope (integration kit for the current project). Slight deduction: the retrieval action itself is never literally stated — 'get' comes from the title, and the GET fallback endpoint implies the fetch.

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

Usage Guidelines3/5

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

It offers a concrete alternative path for a withheld reply ('Same kit at GET https://www.boosthis.com/api/kit/<runtime>') and conditions on include_files ('no shell') and install_command. The final sentence warns that writing files is not installation, which steers an agent away from treating this as a setup action. However, there is no explicit when-to-use versus sibling tools such as boosthis_verify_kit_install or boosthis_get_removal_kit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target a distinct resource or workflow: alerts, budgets, crashes, traces, jobs, promises, kits, and rules. A few summary-style tools such as snapshot, session_summary, and what_should_i_look_at_next overlap in spirit, but their descriptions clarify the different aggregation levels and purposes.

Naming Consistency4/5

All tools share the consistent boosthis_ snake_case prefix, making the family immediately recognizable and predictable. However, naming mixes noun-resource styles with verb-command styles, and a few names are question-like phrases such as boosthis_what_should_i_look_at_next and boosthis_which_kits.

Tool Count3/5

At 26 tools, this is on the heavy side and slightly past the 16-25 range where a large toolset starts to feel burdensome. The count is defensible because each tool maps to a distinct observability or kit-management concern, but agents will need to do significant selection work.

Completeness4/5

The surface covers a broad lifecycle: kit installation and verification, rules and code matching, performance snapshots and trends, crash risk, release checks, promises, alerts, and connection status. It is mostly read-only by design, so the lack of write operations beyond remember_promise is not a major gap, though alert and job management actions are intentionally absent.

Resources