Skip to main content
Glama
arbadacarbaYK

gittr-mcp

by arbadacarbaYK
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

mirrorRepo

Same result as the website Push of a GitHub/GitLab repo. Copies the forge commits onto gittr (keeps history, updates an existing repo), announces the same git servers as the website, and publishes the branch tips with HEAD on the forge…

Instructions

Same result as the website Push of a GitHub/GitLab repo. Copies the forge commits onto gittr (keeps history, updates an existing repo), announces the same git servers as the website, and publishes the branch tips with HEAD on the forge default branch. A second call keeps the existing name, description, and web links unless you pass new ones. Do not follow this with pushToBridge. If the forge returns 403 (account suspended or blocked), do not call this again and do not pass a different URL to change the source: this copies that URL onto the gittr bare repo and replaces every branch. Read the existing copy with bridgeListFiles after git ls-remote on https://git.gittr.space//.git. A new forge URL is not a way to leave a dead host: the owner uses the website sidebar If this git host is gone. See docs/AGENT-WORKFLOW.md.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
webNoWebsite links. Omit to keep the links already announced.
nameNoDisplay title. Omit to keep the title already announced.
relaysNo
privkeyNoPrivate key (auto-loaded)
repoNameYesgittr repo name (the d tag), not the display title
sourceUrlYesGitHub or GitLab clone URL
publicReadNofalse = private mirror. Default true.
descriptionNoOmit to keep the description already announced.
graspServerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.12
    • changedInput schema / properties / description / description
      Previous value: -"Description"New value: +"Omit to keep the description already announced."
    • addedInput schema / properties / name
      Added value: +{
+  "description": "Display title. Omit to keep the title already announced.",
+  "type": "string"
+}
    • changedInput schema / properties / repoName / description
      Previous value: -"Name for the new repo"New value: +"gittr repo name (the d tag), not the display title"
    • addedInput schema / properties / web
      Added value: +{
+  "description": "Website links. Omit to keep the links already announced.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observedv1.0.3

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does a genuinely good job: it discloses that history is kept, the repo must already exist, branch tips and HEAD are published on the forge default branch, a new source URL replaces every branch, and 403 signals a suspended/blocked account. The mutation severity is made explicit rather than left to inference.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The content sits in a single bloated paragraph mixing purpose, error handling, follow-up reads, and a docs pointer. Several clauses are repetitive ('do not call this again and do not pass a different URL' / 'A new forge URL is not a way to leave a dead host'). Front-loading is weak and structural separation is absent.

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 complex, mutating, no-annotation tool with 9 parameters, the description covers the important behavioral and failure modes (403, URL replacement, idempotent keep-behavior, follow-up read). There is no output schema, but the description implies the result is the mirrored repo state. Complete enough for correct invocation.

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 already 78%, so the baseline is 3, but the description adds genuine meaning: it clarifies that a second call retains existing name/description/web unless new values are passed, and that sourceUrl overwrites the gittr bare repo and all branches. This goes beyond the terse schema strings.

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?

States a specific verb and resource: 'Copies the forge commits onto gittr (keeps history, updates an existing repo)'. It also carves out a boundary against siblings via 'Do not follow this with pushToBridge' and 'Read the existing copy with bridgeListFiles'. The clarity is slightly blunted by being packed into a dense run-on paragraph, but an agent can identify the operation.

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?

Offers real when/when-not guidance: don't chain with pushToBridge, don't retry or swap the URL on a 403, and a new URL is not the way to abandon a dead host. It points to bridgeListFiles as the read path. However, it doesn't name the positive alternative for the 'dead host' case beyond an oblique website sidebar reference.

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

Deploy Server

Other Tools