Skip to main content
Glama

Ciro Cesar Maciel — Free Tools

by click.ciromaciel
OverviewDiscussionsAdmin

Server Details

Free, no sign-in: favicons, web to Markdown, CSV to chart, text to speech, time zones, passwords.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 22 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.7/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a completely different task — timezone comparison, chart rendering, favicon generation, password generation, text-to-speech, and web scraping. There is no overlap in purpose, so an agent can select the right tool unambiguously from names alone.

Naming Consistency4/5

All names are snake_case, which keeps the surface readable. The verb style varies, though: compare_timezones and generate_favicon/generate_password use verb_noun, while data_to_chart, text_to_speech, and web_to_markdown use a recognizable X_to_Y conversion pattern, so the deviation is minor rather than chaotic.

Tool Count5/5

Six tools is a tight, well-scoped set for a grab-bag utility server; each tool earns its place with a distinct, non-redundant capability. No tool feels like filler or a near-duplicate of another.

Completeness4/5

As a general-purpose free-tools server there is no fixed CRUD domain to cover, and each tool exposes rich options and error handling. The only notable seam is generate_favicon deferring image-mode requests to a host tool (open_favicon_editor) not included in this set, leaving a small workflow gap handled only by fallback instructions.

Available Tools

8 tools
compare_timezonesTime zone comparisonA
Read-only
Inspect

Converts one moment across several time zones, daylight saving time included.

WHEN TO USE: "what time is it in…", scheduling a meeting across cities, checking whether a time falls at night or on another day somewhere.

HOW IT WORKS:

  • zones: IANA time zone names in Area/City form — America/Sao_Paulo, Europe/Lisbon, Asia/Tokyo, UTC. Not city names alone, abbreviations (EST, BRT) or offsets (GMT-3). The FIRST zone is the reference for date and hour. 1 to 12 zones.

  • date (YYYY-MM-DD) and hour (0–23) are read in the first zone. Without them: the current moment. Only hour: that hour today in the first zone. Only date: that day at the current hour.

  • format: 24h (14:00) or 12h (2:00 PM).

RETURNS: the moment in UTC and, for each zone, its local date, weekday, time, UTC offset and dayShift (+1 = next day, -1 = previous day, relative to the first zone). link: this tool's web page with the same comparison.

ERRORS name the unknown zone or the invalid date; fix it and call again.

ParametersJSON Schema
NameRequiredDescriptionDefault
dateNoThe day, as YYYY-MM-DD, in the first time zone. Defaults to today there.
hourNoThe hour, 0 to 23, in the first time zone. Defaults to the current hour there.
zonesNoIANA time zone names, such as America/Sao_Paulo or Europe/London. The first one is the reference. 1 to 12.
formatNoHow times are written: 24h (14:00) or 12h (2:00 PM).24h

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description explains DST handling, default behaviors when date/hour are omitted, the return payload (UTC, local date, weekday, time, offset, dayShift), and a link. It also describes error behavior. This gives the agent a full behavioral model with no need to infer.

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?

The description is organized into clear sections (WHEN TO USE, HOW IT WORKS, RETURNS, ERRORS) and front-loads the core purpose. Each sentence carries information an agent needs, and the structured format makes scanning easy.

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

Completeness5/5

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

Given the tool has no output schema, the description compensates by specifying exactly what is returned. It covers defaults, edge cases (dayShift), and error handling, making it complete for correct invocation without requiring further inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds crucial semantics: the first zone is the reference, zone names must be IANA Area/City (not abbreviations or offsets), and the combinations of date/hour defaults. These details materially change how the tool should be called and are not in the schema.

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?

The description opens with a specific verb and resource: 'Converts one moment across several time zones', including daylight saving time. It clearly distinguishes the tool from the sibling tools, which are unrelated (charting, password generation, TTS, web scraping).

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?

A dedicated 'WHEN TO USE' section gives concrete scenarios (what time is it in…, scheduling meetings, checking day shifts). It does not mention when not to use it or alternative tools, but the sibling set is unrelated, so the guidance is clear enough.

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

data_to_chartData to Chart
Read-only
Inspect

Draws a chart from a CSV table and returns it as an image.

WHEN TO USE: the user wants to see data as a chart, or needs a chart image for a document, a README, a slide or a chat.

HOW IT WORKS:

  • csv: a header row, then data rows. First column: the category (or x value); the next columns: numbers. Use a comma or semicolon as separator; decimals with a point, or with a comma when the separator is a semicolon. Up to 20,000 characters.

  • chartType, and what each one needs: bar, horizontalBar, line, area, pie, donut, funnel — one category column + one numeric column; multiline — one x column + one or more numeric columns (one line per column); scatter — two numeric columns (x, y); heatmap — three columns: row, column, value.

  • title: optional, drawn at the top.

RETURNS:

  • image: a PNG address that IS the chart (rendered on request) — put it straight into Markdown (title) or an . imageSvg: the same as SVG, sharper where SVG is accepted. Both are null when the CSV is too long to fit in an address; then use svg.

  • svg: the chart as SVG markup.

  • link: this tool's web page with the same chart, to edit it.

ERRORS say what is wrong with the CSV (missing columns, non-numeric values, too many rows); fix the data and call again.

ParametersJSON Schema
NameRequiredDescriptionDefault
csvYesThe data as CSV with a header row. First column: category or x value; next columns: numbers. Up to 20,000 characters.
titleNoOptional title drawn at the top of the chart. Empty for none.
chartTypeNoThe kind of chart. See the tool description for the columns each kind needs.bar
generate_backgroundBackground generatorA
Read-only
Inspect

Draws a background or wallpaper at the exact size of a place: YouTube banner, Instagram story, LinkedIn cover, desktop up to 4K here (8K on the web page), phones, video calls, slides.

WHEN TO USE: the user wants a background, wallpaper, cover or banner image for a channel, profile, screen or presentation, or asks what size one of these must be.

HOW IT WORKS: pick format (70 places, each with its size and the safe area that every device shows) and style (blurred petals, veils and hills; steps; geometry such as arcs, tiles, scales, rays; Hilbert curve; folds). colors are 3 to 7 hex colors, first one is the background. The same seed draws the same design in every format, so a set matches.

RETURNS: width, height, format (name, ratio, safe_area in pixels of the file), files (png, jpg and webp addresses: download with curl -o; null above 4K), and link (the web page with the same options, to adjust, add a screenshot on top or download up to 8K).

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNoWhich variation of the design. The same seed and style give the same design in any format.
angleNoDirection, in degrees, for veils, hills, steps, stripes, capsules, chevrons, tides and drape.
grainNoFilm grain, in percent. 10 to 20 hides banding in smooth gradients.
scaleNoSize of the shapes, in percent. Smaller repeats more of the pattern.
styleNopetals, veils, hills (soft blur, macOS-like); steps (flat color bands); arcs, rings, stripes, capsules, tiles, cubes, chevrons, rays, scales, diamonds, squares, truchet (geometry); hilbert, quadtree (fractals); tides, drape (folds).steps
widthNoOnly with format custom.
colorsNo3 to 7 hex colors without #, comma-separated, in order: background first, then outside to inside.2e1f63,4a3a8c,6d5aa8,9682c4,bba9dd,e2d4f0
formatNoWhere the image goes. Examples: youtube-banner, youtube-thumbnail, instagram-story, instagram-portrait, linkedin-banner, linkedin-company, x-header, facebook-cover, meeting-background, slides-16x9, desktop-fhd, desktop-4k, iphone-pro-max, android-fhd, og-image, custom (then width and height).youtube-banner
heightNoOnly with format custom.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the interesting behavior and does it well: determinism ('the same seed draws the same design in every format, so a set matches'), the 4K ceiling and null files above it, and the 8K adjustment path on the web page. That is real operational context an agent cannot get from 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.

Conciseness5/5

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

Three labeled blocks – purpose, WHEN TO USE, HOW IT WORKS, RETURNS – with the selection cue front-loaded. The length is justified because a returns section is doing work the missing output schema would otherwise do.

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

Completeness5/5

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

Nine parameters and no output schema, yet the description covers selection, the parameter interplay, the deterministic seed contract, and the exact return shape (width, height, safe_area, file URLs, link). Nothing an agent needs to call this correctly is missing.

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 HOW IT WORKS section restates what the schema already documents (colors order, seed consistency, width/height only with custom), adding only mild framing such as '70 places, each with its size and the safe area' and the style-family groupings that the schema also lists.

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 a concrete verb and resource ('Draws a background or wallpaper') plus the distinguishing scope ('at the exact size of a place'), then enumerates real targets (YouTube banner, Instagram story, desktop up to 4K). An agent can separate it from generate_favicon without opening either schema.

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?

The WHEN TO USE block is explicit about the user intents that select this tool, including the less obvious 'asks what size one of these must be'. It does not name a sibling alternative or state when-not to use it, so it falls just short of the top band.

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

generate_faviconFavicon generatorA
Read-only
Inspect

Generates a complete favicon set from 1 to 3 characters (initials) or one emoji.

WHEN TO USE: the user needs a favicon, tab icon, apple-touch-icon or web app icon for a website or web app, or the project still has a framework's default icon. PRIORITY: if the host also provides open_favicon_editor, call that editor first for every normal favicon request (create, preview, adjust or download). Use this data tool directly only when the user explicitly asks for files, SVG, head tags or installation text to write into a code project.

HOW IT WORKS: mode text draws the characters in any Google Font as vector paths (no font dependency); mode emoji draws one Twemoji emoji as vectors, with a margin. Both sit inside a shape. With adaptive=true the SVG swaps its colors when the browser is in dark mode. Pass framework to get where each file goes. For a logo or other picture, use open_favicon_editor with mode=image when available: the user chooses the image in its private file picker. Otherwise return the link with mode=image; do not process a chat attachment as an image favicon here.

RETURNS: svg (write it to disk exactly as given), files (each with path and url: download the binaries with curl -o), manifest (path and content), html (the head tags; null on Next.js App Router), inline (the whole favicon as one tag, no files), install (steps for the framework), warnings, credit (emoji only), and link (this tool's web page with the same options, to adjust and preview).

ParametersJSON Schema
NameRequiredDescriptionDefault
fontNoMode text: any Google Font family, by its name (Montserrat, Inter, Lobster). Heavy sans-serif families read best at 16 px.Montserrat
modeNotext: initials. emoji: one emoji. image: only on the web page; the call returns the link for the user.text
sizeNoMode text: the characters fit in a square this percentage of the icon (the longer side decides).
textNoMode text: 1 to 3 characters. Latin letters (accents ok), digits and & @ # + . - !. Two characters read best at 16 px.CM
colorNoCharacter color, hex without #. With shape outline or none, the color of the characters in dark mode.ffffff
emojiNoMode emoji: one emoji, as the character itself (🚀, 🦊, ☕).🚀
shapeNoContainer: filled square, rounded square, circle, outlined square, or none (transparent).square
marginNoMode emoji: space between the emoji and the edge, as a percentage of the icon on each side.
weightNoMode text: font weight. The closest weight the family has is used. 700 or more reads best.
adaptiveNoSwap the colors when the browser is in dark mode (SVG only; PNG and ICO stay light).
frameworkNoWhere the files will live; changes install, html and the file paths only.html
backgroundNoContainer color, hex without #. With shape outline or none, the color of the characters in light mode.141414

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the minimal readOnlyHint/openWorldHint annotations, the description discloses real behavioral traits: text mode renders vector paths with no font dependency, emoji mode uses Twemoji with a margin, adaptive=true swaps colors only in SVG (PNG/ICO stay light), and mode=image returns a link rather than files. It also explains that svg must be written exactly as given and that binaries are downloaded with curl -o.

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

Conciseness4/5

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

It is on the long side, but it is well organized under WHEN TO USE / HOW IT WORKS / RETURNS headings and front-loads the purpose before the routing rule. There is minor redundancy, repeating the open_favicon_editor mode=image guidance twice, which keeps it short of a 5.

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

Completeness5/5

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

With 12 parameters and no output schema, the description carries the return-value burden itself, and the RETURNS block enumerates every output (svg, files, manifest, html, inline, install, warnings, credit, link) with usage notes such as curl for binaries and null html on Next.js App Router. Nothing needed to invoke or consume the result is missing.

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 description coverage is 100%, so the baseline is 3; the description adds genuine cross-parameter meaning by explaining the text/emoji/image mode split and that framework only changes install, html and file paths. The interaction context between mode, adaptive and the returned artifacts goes beyond the per-parameter schema text.

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?

The opening sentence states a specific verb and resource ('Generates a complete favicon set from 1 to 3 characters... or one emoji'), which immediately distinguishes it from the unrelated utility siblings like generate_password or data_to_chart. The scope and supported input modes are unambiguous 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.

Usage Guidelines5/5

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

An explicit WHEN TO USE block names the triggering conditions (favicon, tab icon, apple-touch-icon, default framework icon) and the PRIORITY rule routes normal requests to open_favicon_editor, reserving this tool for explicit file/SVG/head-tag requests. It also states the when-not case ('do not process a chat attachment as an image favicon here'). This is textbook alternative routing.

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

generate_passwordPassword generatorA
Read-only
Inspect

Generates a strong random password with a cryptographically secure generator.

WHEN TO USE: the user asks for a password or a random key.

HOW IT WORKS: always uses upper and lower case letters; numbers and symbols are optional. Each selected kind of character appears at least once. length: 8 to 64 (default 16).

RETURNS: password, the options used, and link — this tool's web page with the same options. The password is never in the link. Show the password to the user as it is; do not store it or repeat it elsewhere.

ParametersJSON Schema
NameRequiredDescriptionDefault
lengthNoNumber of characters, 8 to 64. Default 16.
numbersNoInclude digits 0-9. Default true.
symbolsNoInclude symbols such as !@#$%. Default true. Set false for systems that reject symbols.

TDQS

A4.7/5.0
Behavior5/5

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

Far beyond the sparse annotations, the description discloses important behavior: cryptographic security, mandatory upper/lowercase letters, optional numbers/symbols, guaranteed inclusion of each selected character type, length limits and default, return contents, and the privacy rule that the password is never in the link and should not be stored or repeated. This is rich, actionable transparency.

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?

The description is well-organized with clear WHEN TO USE, HOW IT WORKS, and RETURNS sections. Every sentence provides necessary information, including the security instruction, without redundancy or filler.

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

Completeness5/5

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

With no output schema, the description correctly explains what the tool returns: the password, the options used, and a link. It also covers parameter behavior, length constraints, and handling instructions, making the tool fully callable by an agent without needing external information.

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?

The schema already fully documents all three parameters with descriptions and defaults, giving a high baseline. The description adds useful behavioral semantics beyond the schema, notably that uppercase and lowercase letters are always included and that each selected character kind appears at least once, which explains how the parameters affect the output.

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?

The description opens with 'Generates a strong random password with a cryptographically secure generator,' a specific verb and resource that fully defines the tool's purpose. It also clarifies scope by covering password and random key generation, and the sibling tools are clearly unrelated, so there is no ambiguity.

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?

The 'WHEN TO USE' section explicitly states the tool is for when the user asks for a password or a random key. It does not provide exclusions or name alternative tools, but the sibling set is unrelated and no realistic alternative exists, so the guidance is clear and sufficient.

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

mindmapsMind Maps Generator
Read-only
Inspect

Create and edit mind maps from an outline or a project file. Export PNG, SVG and PDF, save locally and share a link. No account required.

ParametersJSON Schema
NameRequiredDescriptionDefault
outlineNoFirst line is the root; indent following topics by two spaces per level.
projectNo
text_to_speechText to speech
Read-only
Inspect

Reads a text aloud in a natural Portuguese voice from Fish Audio — Rafael by default, or one of six others — and returns an MP3.

WHEN TO USE: the user wants to hear a Portuguese text or needs an audio file of it — narration, audiobook, lesson, voice-over, a message read aloud. The voices speak Portuguese (Brazil, and Tomás from Portugal); a text in another language is read with their accent.

HOW IT WORKS:

  • Up to 50,000 characters per call. A text over 1,000 characters is split by sentence into parts of up to 1,000; the parts are voiced three at a time and joined in order into ONE MP3. Progress is reported per part ("Gerando áudio... 3 de 18"), so keep waiting while it arrives.

  • It takes time: about 25 seconds per round of three parts. 1,000 characters ≈ 25 s; 5,000 ≈ 1 min; 16,000 ≈ 2.5 min; 50,000 ≈ 7 min.

  • Over 50,000 characters: split the text at paragraph boundaries into several calls with the same voice and speed, and give the user every link, in order.

  • Send the text as it should be HEARD: remove Markdown marks (**, #, list bullets), URLs, emojis and tables. Do not summarize, translate or reword unless the user asked — every word you send is read.

  • voice: rafael (default) or beatriz for clear, neutral narration; tomas for European Portuguese; narrador-propagandas for ads; rodolfo, sao-cipriano and capitao-nascimento are deep character voices.

  • speed: 1 is the voice's natural pace; 0.9 suits calm narration, 1.2 a quick read.

RETURNS:

  • audioUrl: the complete MP3 to download, valid for 7 days. Always give this link to the user. If you can run commands, you can download it (e.g. curl -o audio.mp3 ).

  • audio: the MP3 itself, only when it is short (about a minute or less); otherwise null.

  • seconds (duration), parts, characters, voice, speed.

  • link: this tool's web page with the same voice and speed (the text is not in it).

ERRORS say what happened and what to do next. If a part fails, no audio is produced and a new call starts again from part 1.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe text to read aloud: 1 to 50,000 characters. Plain text as it should be heard — no Markdown, URLs or emojis. Longer texts: split into several calls.
speedNoReading speed, 0.5 to 2. 1 is the voice's natural pace; 0.9 calm narration; 1.25 a quick read.
voiceNoThe voice, from Fish Audio: rafael (Rafael, male, pt-BR: Clara e segura, para apresentações e atendimento.); beatriz (Beatriz, female, pt-BR: Clara e segura, para apresentações e atendimento.); tomas (Tomás, male, pt-PT: Clara e segura, em português de Portugal.); narrador-propagandas (Narrador Propagandas, male, pt-BR: Confiante e enérgica, para anúncios e vídeos institucionais.); rodolfo (Rodolfo, male, pt-BR: Grave e calma, para narração e oração.); sao-cipriano (São Cipriano, male, pt-BR: Grave e dramática, de personagem.); capitao-nascimento (Capitão Nascimento, male, pt-BR: Grave e rouca, séria, de personagem.). Default: rafael. All speak Portuguese; tomas is from Portugal.rafael
web_to_markdownWeb page to MarkdownA
Read-only
Inspect

Fetches a public web page and returns its content as clean Markdown.

WHEN TO USE: you need to read a page — documentation, an article, a product page — to answer, summarize or quote it; or the user wants a page as Markdown.

HOW IT WORKS:

  • url: a public http(s) address. Private networks, localhost and addresses with credentials are refused.

  • Reads the HTML the server sends (like a simple browser, without running JavaScript). Pages that build their content with JavaScript have no text to convert — the error says so.

  • onlyMainContent (default true) drops menus, headers, footers, sidebars, cookie banners and ads. Set false to keep the whole page.

  • pages above 1 also follows links on the same site (same folder and below), breadth-first, up to that many pages (max 20), respecting robots.txt. Slower: a few seconds per page.

  • Limits per page: 15 seconds and 5 MB. PDFs and non-HTML files are not converted.

RETURNS: for each page, its Markdown with absolute links and images, plus title, description and language when the page has them; pages that failed are listed with the reason. link: this tool's web page with the same request.

ERRORS say why the page could not be read and whether retrying makes sense.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe page to convert: a public http or https address.
pagesNoHow many pages of the same site to convert, 1 to 20, starting at url and following its links. 1 (default) converts only url.
onlyMainContentNotrue (default): keep only the content, without menus, footers, sidebars, cookie banners and ads. false: the whole page.

TDQS

A5/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint and openWorldHint annotations by disclosing concrete behaviors: no JavaScript execution, private address refusal, link-following behavior, robots.txt respect, per-page time and size limits, PDF/non-HTML handling, return structure, and error semantics. This gives the agent an accurate model of what will happen and what can go wrong.

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?

The description is longer than average, but it is exceptionally well organized with clear headers and bullet points that make the content scannable. Each section earns its place by covering a distinct aspect: purpose, usage, behavior, parameters, return values, and error handling. The core purpose is front-loaded in the first sentence.

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

Completeness5/5

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

Despite having no output schema, the description fully explains what the tool returns, including per-page Markdown, title/description/language metadata, failed page listings, and a reference link. It also covers limits, unsupported file types, and error clarity, leaving no critical gap for an agent deciding whether and how to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial value by explaining real-world meaning: 'url' must be a public http(s) address with private networks refused, 'pages' triggers breadth-first same-site crawling up to 20 pages, and 'onlyMainContent' controls removal of menus, headers, footers, and ads. This enrichment goes well beyond the baseline schema descriptions.

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?

The first sentence states a specific action and resource: 'Fetches a public web page and returns its content as clean Markdown.' This clearly differentiates the tool from its unrelated siblings and immediately tells an agent what it accomplishes.

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

Usage Guidelines5/5

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

The 'WHEN TO USE' section explicitly states appropriate scenarios: reading documentation, articles, or product pages to answer, summarize, or quote; or when the user wants a page as Markdown. It also gives implicit exclusions by noting that private networks, localhost, and credentialed addresses are refused, and that JavaScript-rendered pages have no text to convert.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedtext_to_speech1 field changed
      • addedInput schema / properties / voice
        Added value: +{
+  "default": "rafael",
+  "description": "The voice, from Fish Audio: rafael (Rafael, male, pt-BR: Clara e segura, para apresentações e atendimento.); beatriz (Beatriz, female, pt-BR: Clara e segura, para apresentações e atendimento.); tomas (Tomás, male, pt-PT: Clara e segura, em português de Portugal.); narrador-propagandas (Narrador Propagandas, male, pt-BR: Confiante e enérgica, para anúncios e vídeos institucionais.); rodolfo (Rodolfo, male, pt-BR: Grave e calma, para narração e oração.); sao-cipriano (São Cipriano, male, pt-BR: Grave e dramática, de personagem.); capitao-nascimento (Capitão Nascimento, male, pt-BR: Grave e rouca, séria, de personagem.). Default: rafael. All speak Portuguese; tomas is from Portugal.",
+  "enum": [
+    "rafael",
+    "beatriz",
+    "tomas",
+    "narrador-propagandas",
+    "rodolfo",
+    "sao-cipriano",
+    "capitao-nascimento"
+  ],
+  "type": "string"
+}
  2. 1 tool update
    • Changedtext_to_speech1 field changed
      • removedInput schema / properties / voice
        Removed value: -{
-  "default": "pt-BR-FranciscaNeural",
-  "description": "A Microsoft neural voice; one of the listed ids. Pick one in the text's language — the prefix is language-region (pt-BR, en-US, es-MX…). Default: pt-BR-FranciscaNeural.",
-  "enum": [
-    "pt-BR-FranciscaNeural",
-    "pt-BR-AntonioNeural",
-    "pt-PT-RaquelNeural",
-    "pt-PT-DuarteNeural",
-    "en-US-AriaNeural",
-    "en-US-JennyNeural",
-    "en-US-GuyNeural",
-    "en-US-ChristopherNeural",
-    "en-GB-SoniaNeural",
-    "en-GB-RyanNeural",
-    "en-GB-LibbyNeural",
-    "en-AU-NatashaNeural",
-    "en-AU-WilliamNeural",
-    "es-ES-ElviraNeural",
-    "es-ES-AlvaroNeural",
-    "es-MX-DaliaNeural",
-    "es-MX-JorgeNeural",
-    "fr-FR-DeniseNeural",
-    "fr-FR-HenriNeural",
-    "fr-CA-SylvieNeural",
-    "fr-CA-JeanNeural",
-    "de-DE-KatjaNeural",
-    "de-DE-ConradNeural",
-    "it-IT-ElsaNeural",
-    "it-IT-DiegoNeural",
-    "ja-JP-NanamiNeural",
-    "ja-JP-KeitaNeural",
-    "zh-CN-XiaoxiaoNeural",
-    "zh-CN-YunxiNeural",
-    "ko-KR-SunHiNeural",
-    "ko-KR-InJoonNeural",
-    "ru-RU-SvetlanaNeural",
-    "ru-RU-DmitryNeural",
-    "hi-IN-SwaraNeural",
-    "hi-IN-MadhurNeural",
-    "ar-SA-ZariyahNeural",
-    "ar-SA-HamedNeural",
-    "nl-NL-ColetteNeural",
-    "nl-NL-MaartenNeural",
-    "sv-SE-SofieNeural",
-    "sv-SE-MattiasNeural",
-    "nb-NO-PernilleNeural",
-    "nb-NO-FinnNeural",
-    "da-DK-ChristelNeural",
-    "da-DK-JeppeNeural",
-    "pl-PL-ZofiaNeural",
-    "pl-PL-MarekNeural",
-    "tr-TR-EmelNeural",
-    "tr-TR-AhmetNeural"
-  ],
-  "type": "string"
-}
  3. 1 tool update
    • Addedgenerate_background
  4. 1 tool update
    • Addedmindmaps
  5. 1 tool update
    • Addedgenerate_favicon
  6. 5 tool updates
    • First observedcompare_timezones
    • First observeddata_to_chart
    • First observedgenerate_password
    • First observedtext_to_speech
    • First observedweb_to_markdown

Related MCP Connectors

Related MCP Servers

  • goai_tools_mcp

    Feghal
    A
    license
    Not graded
    quality
    B
    maintenance
    31 deterministic utility tools over one public endpoint: image conversion and lossless EXIF/metadata stripping, App Store screenshot/icon/favicon generation, WCAG and OKLCH colour maths, .strings and provisioning-profile checks, plus TDEE, recipe and plant calculators. No API key, no account, no model calls.
    ISC

  • passiv-mcp

    mahope
    A
    license
    A
    quality
    A
    maintenance
    Provides AI agents with free web tools for converting HTML to Markdown, running EU compliance scans, profiling pages, and checking security headers, with no authentication or dependencies.
    4
    8 npm
    MIT
Try in Browser
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources