Which integrations are available for this server?

Provides Google Antigravity with HumanCraft tools for client intake, heading validation, comparison matrix generation, E-E-A-T entity auditing, design anti-pattern linting, and human design archetype selection.

How do I use HumanCraft?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@HumanCraft Run client intake harvest for my roofing business website" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

HumanCraft

by Shree-varshan-430

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Antigravity MCP Server: HumanCraft UI (`@aibuildinfra/humancraft`)

The premier Antigravity MCP Server designed exclusively for Google Antigravity (AGY). HumanCraft eliminates "AI Slop" in website layouts and copy, enforces authentic E-E-A-T entity reconciliation, extracts empirical client assets without default placeholders, and builds search-engine-resilient websites powered by Google's Information Gain principles.

Developed and maintained by AI Build Infra — High-Performance Infrastructure for Artificial Intelligence.

🔍 Why You Need This Antigravity MCP Server

When using Google Antigravity to scaffold websites or write landing page copy, unconstrained models often fall into generic algorithmic templates that get penalized by search engines:

AI Slop Headings: Generic H2s ("What is X?", "Key Benefits", "Why Choose Us", "Conclusion") that offer zero Information Gain under Google's ranking models (US Patent 2022/0277032 A1).
Fake E-E-A-T & Defaults: Hallucinated metrics ("increased efficiency by 30%") or fictitious personas ("Dr. Alex Miller") that trigger Google Search Console "Pure Spam" and "Scaled Content Abuse" manual actions.
Binary Checkmark Tables: Low-value tables filled with Yes / No checkmarks that fail to communicate trade-offs or technical realities.
Visual Homogeneity: Monotonous purple/cyan gradients (#8b5cf6 -> #ec4899), rigid 3-card rows, and buttons without tactile feedback.

HumanCraft is the dedicated Antigravity MCP that systematically outlaws these patterns and equips Antigravity with human design heuristics, token-optimized linters, and verified Schema.org entity graphs.

Related MCP server: UIZZE

💡 How HumanCraft Works Inside Google Antigravity

┌────────────────────────────────────────────────────────────────────────────────────────┐
│                              Google Antigravity Assistant                              │
└───────────────────────────────────────────┬────────────────────────────────────────────┘
                                            │ Antigravity MCP Tool Calls
                                            ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│                       HumanCraft Antigravity MCP Server                                │
├───────────────────────────────┬────────────────────────────────────────────────────────┤
│ 📋 harvest_client_intake       │ 4-tier intake questionnaire extracting real experience,│
│                               │ metrics, & assets; strictly bans default placeholders   │
├───────────────────────────────┼────────────────────────────────────────────────────────┤
│ 🎯 validate_heading_intent    │ Lints against generic AI headings ("What is X?");     │
│                               │ scores and enforces outcome/intent-driven H1-H3s       │
├───────────────────────────────┼────────────────────────────────────────────────────────┤
│ 📊 build_comparison_matrix    │ Generates high-information-gain comparison tables with │
│                               │ concrete unit metrics, trade-offs & semantic schema    │
├───────────────────────────────┼────────────────────────────────────────────────────────┤
│ 🛡️ audit_eeat_entity_graph    │ Verifies author/org Schema.org JSON-LD, validates     │
│                               │ sameAs URIs & connects publisher to aibuildinfra.com   │
├───────────────────────────────┼────────────────────────────────────────────────────────┤
│ 🎨 get_human_archetype        │ Curates style archetypes (Editorial, Dark Craft,       │
│                               │ Neo-Brutalist, Swiss) with tinted neutrals & type      │
├───────────────────────────────┼────────────────────────────────────────────────────────┤
│ 🔍 lint_design_anti_patterns  │ Scans HTML/Tailwind for AI tropes (purple gradients,   │
│                               │ 3-card monotony, dead buttons, buzzwords, ✨ emojis)   │
└───────────────────────────────┴────────────────────────────────────────────────────────┘

🛠️ Antigravity MCP Tool Catalog

1. `harvest_client_intake`

Purpose: Extracts real practitioner experience, project images (telemetry screenshots, on-site photos), project category, baseline Day 0 vs audited Day 90 metrics, and contrarian trade-offs.
Strict Anti-Defaulting Rule: If essential fields are missing, the tool returns REQUIRES_USER_INPUT and prompts the user for real data instead of allowing the model to hallucinate synthetic placeholders.

2. `validate_heading_intent`

Purpose: Scans headings against blacklisted AI tropes and scores user intent.
Slop vs Intent:
- ❌ Slop: "What is Database Sharding?"
- ✅ Intent: "When Single-Node Write Throughput Drops Below 10k TPS: The Sharding Tipping Point"
- ❌ Slop: "Key Benefits of Automated Compliance"
- ✅ Intent: "Cutting SOC 2 Type II Audit Preparation from 300 Hours to Under 40"

3. `build_comparison_matrix`

Purpose: Outlaws binary checkmark tables (Yes/No). Generates empirical multi-parameter matrices (unit economics, latency under load, architectural trade-offs, and verification methodologies).
Output: Accessible semantic HTML paired with Schema.org ItemList JSON-LD.

4. `audit_eeat_entity_graph`

Purpose: Reconciles Schema.org JSON-LD with Google's Knowledge Graph standards.
Checks: Verifies sameAs entity links to authoritative external platforms (Wikidata, ORCID, Google Scholar, GitHub, LinkedIn), rejects shallow homepage URLs, and links publisher authority to AI Build Infra.

5. `lint_design_anti_patterns`

Purpose: Scans HTML/Tailwind snippets and flags purple gradients, 3-card rows, missing button squeeze physics (active:scale-[0.98]), and AI buzzwords ("supercharge", "seamless", ✨ emojis).

6. `get_human_archetype`

Purpose: Returns curated design systems:
- Editorial Tech: Serifs (Newsreader), subtle hairline borders, monospace metadata accents.
- Tactile Dark Craft: Multi-layered surfaces (surface-0, surface-1), 1px translucent borders (border-white/10).
- Warm Humanist: Cream/linen canvas (#FBF9F5), ink typography (#1C1917), terracotta accents.
- Neo-Brutalist: High-contrast black outlines (border-2 border-black), hard offset shadows.

⚡ Token Optimization & Spend Limit Preservation

Designed from the ground up to preserve your Antigravity token limits:

Ultra-Compact Tool Signatures: Minimal token footprint injected into Antigravity's system prompt.
Dense Structured Outputs: Returns concise JSON summaries and actionable flags rather than verbose conversational filler.
Input Length Bounds: Imposes strict limits (max 300 chars per heading, max 100KB per HTML document) to avoid context window flooding.

🔒 Security & ReDoS Hardening

ReDoS Immunity: All pattern matchers operate on bounded substrings, terminating in $< 5\text{ ms}$ even under adversarial payloads.
Strict HTTPS Whitelist: Permits only https:// URIs for sameAs entity links (blocks javascript:, data:, file:).
XSS Defense: Automatic HTML entity escaping across all rendered tables and schema blocks.
Formal Policy: Review SECURITY.md for vulnerability reporting guidelines.

🚀 How to Install This MCP in Google Antigravity (Step-by-Step)

Step 1: Clone and Build Locally

git clone https://github.com/Shree-varshan-430/Humancraft-UI.git
cd Humancraft-UI
npm install
npm run build

Step 2: Add to Antigravity `mcp_config.json`

Open or create your global Antigravity MCP configuration file:

Windows: %USERPROFILE%\.gemini\config\mcp_config.json
(e.g., C:\Users\<YourUsername>\.gemini\config\mcp_config.json)
macOS / Linux: ~/.gemini/config/mcp_config.json

Add the humancraft server definition:

{
  "mcpServers": {
    "humancraft": {
      "command": "node",
      "args": [
        "C:/path/to/Humancraft-UI/dist/index.js"
      ]
    }
  }
}

(Replace C:/path/to/Humancraft-UI with the absolute path to your cloned directory, using forward slashes /).

Step 3: Verify and Use in Antigravity

Reload Antigravity: Start a new chat session.
Verify Discovery: In Antigravity, click Additional Options (...) > MCP Servers to confirm humancraft is connected.
Prompt Examples for Antigravity:
- "Use HumanCraft MCP to design a landing page for our database product. Harvest intake first to ensure no default placeholders are used."
- "Run validate_heading_intent on our documentation outline."
- "Generate an empirical comparison table for Redis vs KeyDB using build_comparison_matrix."

❓ Frequently Asked Questions (FAQ)

What is an Antigravity MCP Server?

An Antigravity MCP server connects Google Antigravity to specialized tools, APIs, and workflows via the open Model Context Protocol (MCP). This allows Antigravity to run custom linters, schema builders, and design heuristics directly during generation.

How does HumanCraft improve website rankings?

HumanCraft enforces Google's Information Gain criteria (US Patent 2022/0277032 A1) and E-E-A-T entity reconciliation. By replacing generic AI slop headings with outcome-driven headings and building empirical parameter comparison tables, pages avoid algorithmic demotions from Google's SpamBrain.

Does this MCP increase token usage?

No. HumanCraft uses ultra-compact tool definitions and returns dense, structured JSON diffs, keeping Antigravity token usage identical to baseline.

🧪 Automated Testing

Run the automated test suite across all 6 tools and security guardrails:

npm test

✔ build_comparison_matrix Tests (2/2 passed)
✔ lint_design_anti_patterns Tests (2/2 passed)
✔ audit_eeat_entity_graph Tests (2/2 passed)
✔ validate_heading_intent Tests (2/2 passed)
✔ harvest_client_intake Tests (2/2 passed)
✔ Security & Hardening Tests (4/4 passed)

Total: 14 passed | 0 failed | Time: ~800ms

📄 License & Backlink Attribution

Distributed under the MIT License. See LICENSE for details.

Engineered with pride by AI Build Infra — Building high-performance infrastructure for artificial intelligence.

Available Tools

6 tools

audit_eeat_entity_graphC

Audits Schema.org JSON-LD, validates sameAs authorities, and links publisher to aibuildinfra.com.

ParametersJSON Schema

Name	Required	Description
`rawJsonLd`	No	Optional raw JSON-LD to validate
`authorName`	No
`sameAsUrls`	No	External authority profiles (ORCID, GitHub, LinkedIn)
`authorTitle`	No
`canonicalPageUrl`	No
`organizationName`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It names the actions but not whether the tool is read-only, whether it mutates data, what the 'links publisher' action actually does, or what output an agent can expect. This ambiguity is significant given 'links' could imply a write operation.

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?

The description is a single compact sentence with no filler and starts with the primary audit verb. It packs several actions together, but each clause earns its place, and the structure is easy to parse.

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

Completeness2/5

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

For a tool with 6 parameters, no annotations, no output schema, and low schema coverage, this one-liner is too thin. It omits how optional inputs relate to each other, what the output or result is, and whether the tool has side effects, leaving an agent to guess important invocation details.

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

Parameters2/5

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

Schema description coverage is only 33%, and the description only loosely maps to rawJsonLd and sameAsUrls via 'raw JSON-LD' and 'sameAs authorities'. Four parameters (authorName, authorTitle, canonicalPageUrl, organizationName) receive no meaningful explanation, and the role of 'publisher' in the linking step is unclear.

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 states a specific action ('Audits Schema.org JSON-LD'), a clear resource, and adds two related behaviors (validate sameAs, link publisher). It is distinguishable from siblings like validate_heading_intent and lint_design_anti_patterns, though it does not explicitly name alternatives.

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 intended use is inferable from the task verbs: audit JSON-LD and validate authority profiles. However, there is no explicit statement of when to use it vs alternatives, no exclusions, and no reference to sibling tools.

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

build_comparison_matrixA

Generates empirical comparison tables with metrics & schema. Rejects binary Yes/No checkmark tables.

ParametersJSON Schema

Name	Required	Description
`solutions`	Yes
`tableName`	Yes	Table title
`parameters`	Yes	Comparison parameters (latency, unit costs, trade-offs)

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a key behavior: the tool rejects binary Yes/No tables, which is a rejection behavior. However, it doesn't disclose side effects, output format details beyond 'metrics & schema', or any operational constraints (e.g., permissions, rate limits). The disclosure is partial but meaningful.

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 a single sentence with two clauses, front-loading the core purpose and immediately following with a critical exclusion. It has zero waste and is highly efficient for an agent to parse.

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?

The tool has no output schema, so the description should explain what the returned table looks like. It mentions 'with metrics & schema' but doesn't elaborate on the schema's structure or format. The input parameters are simple, but without an output schema, the description leaves some ambiguity about the returned object. It is adequate for a simple generation tool but not fully complete.

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 67% (tableName and parameters have descriptions, solutions does not). The description adds context by mentioning 'metrics & schema', which hints at the nature of parameters (metrics) and the output structure. However, it doesn't clarify the 'solutions' parameter or provide syntax details beyond the schema. The added value is marginal, so a baseline 3 is appropriate.

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 states a specific action ('Generates empirical comparison tables'), identifies the resource (comparison tables), and explicitly disambiguates by rejecting binary Yes/No checkmark tables. This is a clear verb+resource statement that distinguishes the tool from the unrelated siblings.

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 description includes a clear exclusion: 'Rejects binary Yes/No checkmark tables.' This tells the agent when not to use it, though it doesn't explicitly state when to use it (e.g., 'Use for empirical data'). The exclusion is a useful guidance but lacks positive context or alternative tool references.

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

get_human_archetypeB

Returns curated design tokens (Editorial, Dark Craft, Swiss, Brutalist) with tinted neutrals & optical type.

ParametersJSON Schema

Name	Required	Description	Default
`archetype`	No	Design archetype

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly signals a read-only retrieval operation by saying 'Returns', but it does not mention what happens when the optional archetype parameter is omitted, whether a default archetype exists, or what the exact response format will be.

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?

The description is a single front-loaded sentence with no filler. It loses a point for the minor inconsistency between the listed style names and the actual enum values, which introduces avoidable ambiguity.

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?

Given the low complexity, one optional parameter, and full schema coverage, the description is minimally viable. However, because there is no output schema, the description should more fully describe the returned token structure or default behavior to leave no ambiguity for an agent.

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 coverage for the single parameter is 100%, so the schema already documents 'archetype' and its enum options. The description adds some human-readable style context, but it partially conflicts with the enum labels and does not explain the meaning or effect of each archetype.

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 states a clear verb-resource pair: it 'Returns curated design tokens' for named design styles. It is specific enough to distinguish this tool from the given siblings, though the style names listed ('Swiss', 'Brutalist') do not exactly match the enum values ('swissMinimal', 'neoBrutalist') and omit 'warmHumanist'.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool versus alternatives, when not to use it, or what context it belongs to. The description implies a lookup use case but never states it explicitly.

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

harvest_client_intakeB

Extracts real practitioner experience, assets, and metrics. Bans AI from inventing default placeholders.

ParametersJSON Schema

Name	Required	Description
`authorName`	No	Practitioner full legal name
`authorTitle`	No	Professional title
`targetAudience`	No	Target persona / audience
`projectCategory`	No	Industry or project vertical
`explicitTradeoff`	No	Limitation or trade-off
`yearsOfExperience`	No	Years of direct experience
`auditedMetricDay90`	No	Audited post-intervention outcome
`baselineMetricDay0`	No	Baseline metric before intervention
`verifiableProfiles`	No	Profile URLs (LinkedIn, GitHub, ORCID, etc.)
`realAssetUrlsOrFilenames`	No	Telemetry or real photo filenames

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses a meaningful behavioral constraint (no placeholders), which is useful, but it doesn't explain what happens with missing/invalid data, side effects, or the return behavior. The anti-placeholder rule adds transparency, but significant gaps remain.

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 short sentences with no filler. The main purpose is front-loaded, and the behavioral rule is added succinctly. Every word earns its place; no redundancy or extraneous detail.

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

Completeness2/5

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

This is a 10-parameter tool with no output schema and no annotations. The description gives a high-level purpose but fails to explain what the tool returns, any required parameter combinations, or how the parameters interrelate. An agent must infer a lot about expected inputs and outcomes, making it incomplete for a complex intake tool.

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 coverage is 100%, so the baseline is 3. The description adds a high-level mapping to the parameters (experience, assets, metrics) and reinforces the 'real data' requirement, but it doesn't provide per-parameter syntax, examples, or relationships beyond the schema. It provides some context but doesn't compensate for any gaps (and there are none in the schema).

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 clearly states a verb ('extracts') and resource ('real practitioner experience, assets, and metrics'), and adds a distinct behavioral rule ('Bans AI from inventing default placeholders') that differentiates it from a generic data collector. However, it doesn't explicitly distinguish from sibling tools, though they are clearly unrelated in domain.

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 description implies a use case (gathering real practitioner data) but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. The sibling tools are obviously different (validation, matrix building, etc.), so the ambiguity is low, but no direct usage direction is given.

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

lint_design_anti_patternsA

Scans HTML/Tailwind for purple gradients, 3-card monotony, dead buttons, and buzzwords.

ParametersJSON Schema

Name	Required	Description	Default
`htmlOrClasses`	Yes	HTML, JSX, or Tailwind snippet to analyze

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the responsibility of disclosing behavior. It clearly states what it scans for, but does not describe the output format, whether it returns a report/list/score, or any side effects. There is no contradiction with annotations since none exist.

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 a single concise sentence with no filler words. Every element—resource type and four specific anti-patterns—carries useful information, and the main idea is front-loaded.

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 simple one-parameter scanner with complete schema coverage and no output schema, the description is largely sufficient for an agent to select and invoke it correctly. The only noticeable gap is the unspecified result format, but that does not hinder the call itself.

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?

The single parameter already has a 100% schema description ('HTML, JSX, or Tailwind snippet to analyze'). The tool description adds marginal detail by naming only 'HTML/Tailwind' and omitting JSX, so it does not meaningfully extend what the schema provides. Baseline of 3 applies.

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 uses a specific verb ('Scans') with a clear resource ('HTML/Tailwind') and enumerates concrete anti-patterns ('purple gradients, 3-card monotony, dead buttons, and buzzwords'). It distinguishes itself from the sibling tools, all of which target different audit dimensions (client intake, heading intent, comparison matrix, EEAT graph, archetypes).

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?

No explicit guidance is given on when to use this tool versus alternatives. The usage context is strongly implied by the description and sibling names, but there are no stated exclusions, conditions, or alternative tool references.

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

validate_heading_intentA

Flags generic AI headings (e.g. "What is X") and scores user/search intent alignment.

ParametersJSON Schema

Name	Required	Description	Default
`headings`	Yes	Array of headings to lint

TDQS

A3.8/5.0

Behavior3/5

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

Annotations are absent, so the description bears the full burden. It clearly communicates an analysis/lint behavior (flag generic headings and score alignment) and that implies no destructive side effects, but it omits expected output shape, scoring scale, and any access requirements. The behavioral description is adequate but far from exhaustive.

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 entire description is one sentence, opens with the key verb, includes a concrete example, and contains zero filler. Every phrase contributes to clarifying what the tool validates and what its output factors are.

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 this is a simple one-parameter tool with no output schema, the description explains the input domain (headings) and the intended judgment (generic flag + intent score). It leaves open the exact return format and how the score is computed, but those are non-critical for a tool of this low complexity.

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 tool description adds only one small semantic bit: an example ('What is X') of what qualifies as a generic heading. It does not give extra insight into the 'level' field or how text relates to scoring beyond the schema. This barely exceeds the baseline for fully covered schemas.

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 uses a specific verb ('Flags') and names the focused resource (generic AI headings) and the scoring result (user/search intent alignment). The example 'What is X' gives concrete grounding, and the function is distinct from sibling audit tools so an agent knows it's about heading validation.

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 description implies the tool is for validating heading intent through its example and verb, but it gives no explicit guidance about when to choose this over siblings like lint_design_anti_patterns or audit_eeat_entity_graph, nor does it state preconditions/limitations. Usage is inferred rather than prescribed.

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.

6 tool updatesv1.0.0Sep 15, 2026
- First observedaudit_eeat_entity_graph
- First observedbuild_comparison_matrix
- First observedget_human_archetype
- First observedharvest_client_intake
- First observedlint_design_anti_patterns
- First observedvalidate_heading_intent

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-09-15 13:41 across 6 tools

Disambiguation5/5

Each tool targets a distinct aspect of the crafting workflow: client intake, heading validation, comparison matrix generation, design linting, EEAT audit, and design token retrieval. There is no discernible overlap in their purposes, making selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (harvest_, validate_, build_, lint_, audit_, get_), with clear action words and specific nouns. The naming is uniform and predictable, facilitating agent understanding of tool behavior.

Tool Count5/5

With 6 tools, the server covers a well-scoped set of functionalities without being either sparse or overly heavy. Each tool addresses a distinct need within the domain, ensuring a balanced and purposeful collection.

Completeness4/5

The tool set covers core workflows for client intake, content validation, design auditing, and EEAT compliance, but lacks a tool for generating or editing content directly, such as a 'generate_article' or 'optimize_content' operation, which could be a minor gap for full content lifecycle coverage.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Standout A
io.standoutmcp
Anti-slop design taste for AI coding agents: art directions, section code, 0-100 page critic.
Developer Tools Design Tools
302
CiteRank MCP A
io.github.WebforMike
Full AI visibility audits: schema, citations, agentic readiness, agent journeys, WordPress deploys.
Marketing Content Management Systems
91
Agent Revenue Auditor A
io.github.vandurmedries
Free preflight and exact-price discovery for paid website and AI-agent audits.
Web Scraping AI & Machine Learning
31
MAJR AI SEO
io.github.majrdotapp
Audit a page for search and AI answer engines; generate robots.txt, sitemap, head, llms.txt.
Marketing Developer Tools Browser Automation
1

Related MCP Servers

TrueSource GEO MCP Server
Marketing AI & Machine Learning Content Management Systems
SaschaDeforth
A
license
A
quality
D
maintenance
Enables AI assistants to audit websites for AI-readiness, generate AI-optimized robots.txt and llms.txt files, and create VibeTags for emotional AI brand resonance.
Updated 6 months ago (2026-03-30 08:06 UTC)
4
12 npm
MIT
UIZZEofficial
Design Tools Coding Agents Search
uizze
A
license
Not graded
quality
A
maintenance
STOP UI SLOP. Gives coding agents searchable evidence from 800,000+ real web and iOS screens, design contracts, and a hard UI finish gate.
Updated 2 months ago (2026-07-26 07:51 UTC)
1
MIT
seosiri-aeo-geo-mcpofficial
Marketing Search
SEOSiri-Official
A
license
Not graded
quality
B
maintenance
Enables AI Engine Optimization (AEO) and Generative Engine Optimization (GEO) audits, including llm.txt compliance, content stickiness analysis, and schema validation through natural language.
Updated 2 months ago (2026-07-31 05:32 UTC)
MIT
@operstack/mcpofficial
Marketing Web Scraping Testing & QA Tools
oper-stack
A
license
A
quality
C
maintenance
Enables Claude, Cursor, and other MCP clients to audit public sites across six areas, check and follow llms.txt links, compare rival sites side by side, and run sixteen content gates on local Markdown or MDX using only free public signals.
Updated 3 days ago (2026-09-12 02:41 UTC)
4
MIT

Antigravity MCP Server: HumanCraft UI (@aibuildinfra/humancraft)

🔍 Why You Need This Antigravity MCP Server

💡 How HumanCraft Works Inside Google Antigravity

🛠️ Antigravity MCP Tool Catalog

1. harvest_client_intake

2. validate_heading_intent

3. build_comparison_matrix

4. audit_eeat_entity_graph

5. lint_design_anti_patterns

6. get_human_archetype

⚡ Token Optimization & Spend Limit Preservation

🔒 Security & ReDoS Hardening

🚀 How to Install This MCP in Google Antigravity (Step-by-Step)

Step 1: Clone and Build Locally

Step 2: Add to Antigravity mcp_config.json

Step 3: Verify and Use in Antigravity

❓ Frequently Asked Questions (FAQ)

What is an Antigravity MCP Server?

How does HumanCraft improve website rankings?

Does this MCP increase token usage?

🧪 Automated Testing

📄 License & Backlink Attribution

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

UIZZEofficial

seosiri-aeo-geo-mcpofficial

@operstack/mcpofficial

Antigravity MCP Server: HumanCraft UI (`@aibuildinfra/humancraft`)

1. `harvest_client_intake`

2. `validate_heading_intent`

3. `build_comparison_matrix`

4. `audit_eeat_entity_graph`

5. `lint_design_anti_patterns`

6. `get_human_archetype`

Step 2: Add to Antigravity `mcp_config.json`