Skip to main content
Glama
Antigravity Master MCP Gateway

Antigravity Master MCP Gateway

by ALDY711

sync_skills_from_github

Sync and update your skills library from a GitHub repository, pulling changes to keep your local skill set aligned with the source.

Instructions

Sinkronisasi dan perbarui pustaka skills dari repositori GitHub (secara default menarik dari ALDY711/apk-reverse-modifikasi).

Input Schema

NameRequiredDescriptionDefault
repoNoURL atau slug GitHub repo (default: 'ALDY711/apk-reverse-modifikasi')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It discloses that the default operation pulls from ALDY711/apk-reverse-modifikasi and updates the library, but it does not explain whether local changes are overwritten or merged, which branch or ref is used, authentication or network requirements, or partial-failure behavior.

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?

A single front-loaded sentence compactly states the action, resource, source, and default repository. There is no filler or structural clutter, and the repeated default remains directly useful for invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Basic invocation is clear for a tool with one optional, fully documented parameter. However, without annotations or an output schema, a mutating network synchronization tool needs more detail about overwrite or merge behavior, source selection and authentication, and success or failure outcomes to support fully reliable use.

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%, and the repo field already documents its URL-or-slug format and default value. The description repeats the default repository but adds no further parameter semantics, so the schema appropriately does most of the work.

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 description uses specific verbs (“Sinkronisasi dan perbarui”) and identifies both the resource (“pustaka skills”) and the GitHub source, including a concrete default repository. Its action is implicitly distinct from the list, search, and guide siblings, but it does not explicitly differentiate itself from them.

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?

The wording implies that the tool should be used when the skills library needs to be refreshed from GitHub. It provides no explicit prerequisites, when-not guidance, or direction to inspection siblings such as list_antigravity_skills or search_skills when synchronization is unnecessary.

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