Skip to main content
Glama
Akxan

google-seo-mcp

by Akxan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Fetch an image, convert it on the server, commit it to GitHub

github_commit_image
Destructive

Download, convert, and resize a source image, then commit it and any variants straight to a repo branch in a single commit, all server-side without touching your local machine.

Instructions

Download an image from a public URL, convert it (webp by default), resize or cover-crop it, optionally add variants (e.g. a card thumbnail), and commit every output to a branch in one commit. Runs entirely on the server, nothing on the client machine. Use dryRun to see resulting dimensions and bytes first; then register the file in the site's code with github_commit_files (edits).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesDestination path in the repo, e.g. 'public/assets/img/blog/cover.webp'.
repoYesRepository as 'owner/name', e.g. 'octocat/my-site'.
focusNoCrop anchor: 'attention' keeps the visually busiest region, 'centre' crops symmetrically.attention
widthNoTarget width. With height too, the image is cover-cropped to exactly that size; alone, height follows the aspect ratio. Never upscaled.
branchYesBranch to commit to, e.g. 'main'.
dryRunNoFetch and convert, report dimensions and bytes, commit nothing.
formatNowebp
heightNo
messageYesCommit message in the repository's conventions.
qualityNo
variantsNoExtra outputs from the same source (same format/quality/focus), e.g. a 1000×562 card version.
sourceUrlYeshttp(s) URL of the source image: an image already on a site, a CDN, a shared Google Drive link (uc?export=download&id=…), etc.
createBranchNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false. The description adds meaningful context beyond them: everything runs server-side (nothing on the client), all outputs land in a single commit, and dryRun commits nothing. It doesn't detail overwrite/conflict behavior or auth needs, keeping it below 5.

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?

Two dense sentences that front-load the main action, then the server-side guarantee and the dryRun workflow. No filler or repetition.

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 13-parameter, destructive, no-output-schema tool, the definition covers the essential mechanics: source URL, conversion, single-commit behavior, dryRun preview, and the follow-up sibling. Minor gaps remain around overwrite/branch-conflict behavior, but overall it is well-covered.

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 69%, so the schema documents most parameters. The description reinforces the dryRun purpose and format default and gives a concrete variant example, but adds little syntax/format detail beyond the schema for the other parameters (focus, quality, createBranch).

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?

States specific verbs and resource: downloads an image, converts (webp default), resizes/cover-crops, and commits outputs to a GitHub branch in one commit. It clearly distinguishes itself from github_commit_files by naming that sibling as the follow-up code-editing step.

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?

Gives explicit workflow guidance: use dryRun first to preview dimensions/bytes, then register the file with github_commit_files (edits). This routes the agent between sibling tools well, but it does not state when NOT to use this tool or address branch/overwrite alternatives.

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