What can you do with this server?

This server helps you automatically generate and enhance README documentation for software projects: * Generate a complete README.md (generate_readme): Create a full README file from project metadata (name, description, language, features, author, license type), including sections for installation, usage, API reference, and contributing guidelines. * Analyze project structure (analyze_project): Provide a list of project files and the server will recommend appropriate README sections and detect the project type (e.g., library, CLI tool, API service). * Suggest README sections (suggest_sections): Get tailored section recommendations based on project type and capabilities (e.g., presence of an API, CLI, or Docker support). * Generate shield.io badges (generate_badges): Produce markdown badge snippets (license, version, build status, etc.) for a GitHub repository by providing the owner and repo name.

Which integrations are available for this server?

Interact with GitHub repositories to generate badge markdown based on repository metadata such as owner, repo name, version, and license. Generate shield.io badges for inclusion in project README files.

de en es ja ko ru zh

Readme Generator AI MCP

by CSOAI-ORG

Overview Schema Related Servers Score Discussions

Python

MCP Scorecard: 74/100

Readme Generator Ai MCP

MEOK AI Labs GSPC License PyPI

README

README.md generator MCP — analyse project structure, generate docs, badges, install instructions. MIT.

🚀 Quick Start

# Install via pip
pip install readme_generator_ai_mcp

# Or install via Smithery
npx -y @smithery/cli@latest install readme-generator-ai-mcp --client claude

Related MCP server: Commit Message AI MCP

✨ Features

MCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance

📖 Documentation

🛡️ Compliance

This MCP server is built with EU AI Act compliance built-in:

✅ Article 9 — Risk Management System
✅ Article 13 — Transparency & Instructions for Use
✅ Article 15 — Bias Detection & Testing
✅ Article 26 — FRIA Support (where applicable)
✅ Article 50 — AI Content Watermarking (where applicable)

Need help getting compliant? Book a free 15-min diagnostic →

🏢 Enterprise

Need custom development, SLA guarantees, or white-label deployment?

Pro: $99/mo — Full MCP suite + EU AI Act tracking
Enterprise: $499/mo — Custom dev + SLA + Dedicated support

View Pricing → | Contact Sales →

🤝 Part of the MEOK Ecosystem

This server is part of the MEOK AI Labs ecosystem — 300+ MCP servers for sovereign AI governance.

Domain	Purpose
councilof.ai	EU AI Act compliance marketplace
safetyof.ai	AI safety & monitoring
meok.ai	Sovereign AI platform
cobolbridge.ai	Legacy modernization

📜 License

MIT © CSOAI-ORG

Pairs with MEOK Governance Suite

Build something that touches users? You need compliance. MEOK ships 38 governance MCPs that drop in alongside this tool — EU AI Act, DORA, NIS2, CRA, GDPR, ISO 42001, FDA SaMD, MDR, Basel, MiFID II, MiCA, COPPA, and more.

# One-shot install of the governance pack
npx meok-setup --pack governance

Free tier: 10 calls/day per MCP. Pro tier (£79/mo): unlimited + cryptographically signed compliance attestations your auditor verifies independently.

→ Full catalogue: councilof.ai/catalogue → MEOK AI Labs: meok.ai

💸 Try MEOK in 30 seconds — instant buy ladder

Tier	Price	What you get	Stripe
Smoke test	£1	Signed sample MCP-Hardening report + Article 50 PDF	https://buy.stripe.com/5kQ6oJ0xS3ce8sl7ew8k91j
Quick Kit	£9	EU AI Act Article 50 implementation guide (C2PA + EU-Icon)	https://buy.stripe.com/5kQ6oJ0xS3ce8sl7ew8k91j
Founder Call	£29	30-min 1-on-1 with the founder	https://buy.stripe.com/5kQ6oJ0xS3ce8sl7ew8k91j

Refundable. UK Stripe — VAT-clean. Builds on the 81-MCP MEOK fleet. Verify any signed report at https://meok.ai/verify.

Configuration

Add to your claude_desktop_config.json (Claude Desktop) or your MCP client config:

{
  "mcpServers": {
    "readme-generator-ai-mcp": {
      "command": "uvx",
      "args": ["readme-generator-ai-mcp"]
    }
  }
}

Or: pip install readme-generator-ai-mcp then run the readme-generator-ai-mcp command (stdio transport).

Examples

Once configured, ask your assistant, for example:

"Use generate_readme to …"
"Use analyze_project to …"
"Use suggest_sections to …"

Available Tools

4 tools

analyze_projectA

Analyze project structure from a file list to recommend README sections and detect project type.

Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.

When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.

When NOT to use: Not suitable for real-time production decision-making without human review of results.

Args: file_list (str): The file list to analyze or process. language (str): The language to analyze or process. api_key (str): The api key to analyze or process.

Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.

ParametersJSON Schema

Name	Required	Default
`file_list`	Yes
`language`	No	python
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

No annotations are provided, so the description fully covers behavioral traits: read-only/stateless, authentication requirements, rate limits, error handling, idempotency, and data privacy. This is comprehensive beyond typical annotations.

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

Conciseness3/5

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

The description is well-structured with sections, but it is verbose and redundant: the 'Args' section repeats schema info, and the 'Behavioral Transparency' section partially duplicates the 'Behavior' section. Each sentence could be more focused.

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 the weak parameter semantics, the description comprehensively covers purpose, usage, side effects, and behavioral details. With an output schema present, return values don't need explanation. The tool's complexity (3 params, 1 required) is adequately addressed.

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 0% and the description's 'Args' section merely restates parameter names with generic phrases ('The file list to analyze or process'), adding no meaningful constraints, formats, or examples. Given the lack of schema descriptions, the description fails to compensate.

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 clearly states the tool's purpose: analyze project structure from a file list to recommend README sections and detect project type. This specific verb+resource distinguishes it from sibling tools like generate_readme, which focus on generation.

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?

Explicit 'When to use' and 'When NOT to use' sections provide clear guidance: use for structured analysis, not for real-time decisions without human review. This helps the agent decide between siblings.

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

generate_badgesB

Generate shield.io badge markdown for a GitHub repository.

Behavior: This tool generates structured output without modifying external systems. Output is deterministic for identical inputs. No side effects. Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.

When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.

When NOT to use: Not suitable for real-time production decision-making without human review of results.

Args: owner (str): The owner to analyze or process. repo (str): The repo to analyze or process. badges (str): The badges to analyze or process. version: The version to analyze or process. build": The build" to analyze or process. license_type (str): The license type to analyze or process. version (str): The version to analyze or process. api_key (str): The api key to analyze or process.

ParametersJSON Schema

Name	Required	Default
`owner`	Yes
`repo`	Yes
`badges`	No	license,version,build
`license_type`	No	MIT
`version`	No	1.0.0
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior5/5

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

No annotations are provided, so the description carries full burden. It extensively covers side effects (none), authentication (no auth required for basic, pro tier needs API key), rate limits (10/day free), error handling, idempotency, and data privacy. This is comprehensive and exceeds typical detail.

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 description is verbose and contains redundancy. The 'Behavior' section at the top largely overlaps with the later 'Behavioral Transparency' section. The 'Args' section is a repetitive list with generic descriptions. The structure could be much more concise and front-loaded with only essential info.

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?

While behavioral transparency is well covered, the description fails to explain parameter semantics and does not mention that the output is markdown (even though output schema exists). For a tool with 6 parameters and 0% schema coverage, the description does not provide sufficient context for an agent to correctly invoke it.

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

Parameters1/5

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

Schema coverage is 0% (no descriptions in input schema). The description's 'Args' section merely restates parameter names with the generic phrase 'The ... to analyze or process,' which adds no meaning. It fails to explain what each parameter means in the context of badge generation (e.g., owner as GitHub owner).

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 clearly states the tool's purpose: 'Generate shield.io badge markdown for a GitHub repository.' This is a specific verb+resource combination that distinguishes it from sibling tools (analyze_project, generate_readme, suggest_sections) which focus on analysis or other generation tasks.

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 includes 'When to use' and 'When NOT to use' sections, but the usage guidance is generic and misaligned with the actual tool. It suggests using for 'structured analysis or classification of inputs against established frameworks,' which does not match badge generation. No alternatives are discussed relative to siblings.

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

generate_readmeA

Generate a complete README.md from project metadata including sections for install, usage, API, and contributing.

When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.

When NOT to use: Not suitable for real-time production decision-making without human review of results.

Args: project_name (str): The project name to analyze or process. description (str): The description to analyze or process. language (str): The language to analyze or process. features (str): The features to analyze or process. author (str): The author to analyze or process. license_type (str): The license type to analyze or process. api_key (str): The api key to analyze or process.

ParametersJSON Schema

Name	Required	Default
`project_name`	Yes
`description`	Yes
`language`	No	python
`features`	No
`author`	No
`license_type`	No	MIT
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior5/5

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

With no annotations provided, the description carries full burden and exceeds expectations. It details side effects (read-only, no external modification), authentication (none for basic, api_key for higher tiers), rate limits (10/day free, unlimited pro), error handling (structured errors), idempotency (fully idempotent), and data privacy (no storage). No contradictions 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.

Conciseness3/5

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

The description is well-structured with clear sections, but contains redundant content. The 'Behavior:' and 'Behavioral Transparency:' sections overlap significantly, and the 'Args' section is repetitive. It could be trimmed by merging the behavioral sections and removing the generic 'Args' descriptions, which add no value.

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?

While behavioral transparency is thorough, parameter semantics are weak. The output schema exists but the description does not explain the return format (e.g., plain markdown, structured object). Given the tool's purpose, the description is moderately complete but lacks clarity on what the output looks like and how parameters shape it.

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 0%, so the description must compensate. The 'Args' section only repeats parameter names and types, adding generic phrases like 'The ... to analyze or process.' This adds no meaningful context beyond the schema. For example, 'project_name' is not explained as the name of the project for which the README is generated. This is a significant gap.

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 clearly states 'Generate a complete README.md from project metadata including sections for install, usage, API, and contributing.' This is a specific verb+resource combination that distinguishes it from sibling tools like analyze_project, generate_badges, and suggest_sections, which focus on analysis or partial generation.

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 explicit 'When to use' and 'When NOT to use' sections. It advises using the tool for structured analysis or classification against standards, and warns against real-time production decision-making without review. However, it does not directly compare to siblings, leaving some ambiguity about when to choose this over alternatives.

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

suggest_sectionsA

Suggest appropriate README sections based on project type and capabilities.

When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.

When NOT to use: Not suitable for real-time production decision-making without human review of results.

Args: project_type (str): The project type to analyze or process. has_api (bool): The has api to analyze or process. has_cli (bool): The has cli to analyze or process. has_docker (bool): The has docker to analyze or process. api_key (str): The api key to analyze or process.

ParametersJSON Schema

Name	Required	Description	Default
`project_type`	Yes
`has_api`	No
`has_cli`	No
`has_docker`	No
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations provided, the description fully covers side effects (read-only, no side effects), authentication, rate limits, error handling, idempotency, and data privacy, exceeding the typical burden.

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?

Well-structured with clear headings (Behavior, When to use, etc.), but the behavioral transparency section repeats some information from the Behavior section, making it slightly verbose.

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?

Covers all necessary aspects: input semantics (though weakly), behavior, authentication, rate limits, error handling, idempotency, and data privacy. The presence of an output schema reduces the need for return value descriptions.

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?

The 'Args' section merely repeats parameter names with generic phrases like 'The ... to analyze or process,' adding no meaningful information beyond what the input schema provides. With 0% schema coverage, the description fails to compensate.

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 clearly states the tool suggests README sections based on project type and capabilities, distinguishing it from sibling tools like generate_readme (which generates full README) and generate_badges.

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?

Includes explicit 'When to use' and 'When NOT to use' sections, providing context for appropriate usage. However, it does not directly contrast with the sibling tools, which would strengthen guidance.

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. Dates show when Glama detected each change.

4 tool updatesv1.0.0May 28, 2026
- First observedanalyze_project
- First observedgenerate_badges
- First observedgenerate_readme
- First observedsuggest_sections

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: analyze_project examines file lists, generate_badges creates badge markdown, generate_readme produces a full README, suggest_sections recommends sections. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (analyze_project, generate_badges, generate_readme, suggest_sections) using lowercase and underscores.

Tool Count5/5

With 4 tools covering analysis, suggestion, badge generation, and full README generation, the count is well-scoped for a README generator–neither too few nor too many.

Completeness5/5

The tool set covers the full lifecycle of README creation: analyzing project structure, suggesting sections, generating badges, and producing the complete README. No obvious gaps.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
mcp-flux-proOAuth
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2

Related MCP Servers

Git Helper AI MCP
Version Control Developer Tools
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
Git Helper AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 3 months ago (2026-06-15 14:40 UTC)
14
MIT
Commit Message AI MCP
Version Control AI & Machine Learning Developer Tools
CSOAI-ORG
A
license
A
quality
B
maintenance
Commit Message AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 3 months ago (2026-06-15 14:39 UTC)
4
14
MIT
Code Reviewer AI MCP
Code Analysis Developer Tools Testing & QA Tools
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
Code Reviewer AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 3 months ago (2026-06-15 14:39 UTC)
20
MIT
API Docs Generator AI MCP
Developer Tools Documentation Access
CSOAI-ORG
A
license
A
quality
A
maintenance
API Docs Generator AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 2 days ago (2026-09-04 12:35 UTC)
5
15
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CSOAI-ORG/readme-generator-ai-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server