No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "list-endpoints",
"title": "List API Endpoints",
"description": "Lists all API paths and their HTTP methods with summaries, organized by path. Results can be passed directly into 'get-endpoint'.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"title"
],
"properties": {
"title": {
"type": "string",
"description": "Title of the OpenAPI spec. Use tool 'list-specs' or 'search-endpoints' to see available specs."
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description93/100
Performs a deep search through paths, operations, and parameters to discover relevant API endpoints. Use this tool to find specific API capabilities, required parameters, or data models based on search keywords. Results can be passed directly into 'get-endpoint'.
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
pattern
Search pattern (case-insensitive)
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "search-endpoints",
"title": "Search API Endpoints",
"description": "Performs a deep search through paths, operations, and parameters to discover relevant API endpoints. Use this tool to find specific API capabilities, required parameters, or data models based on search keywords. Results can be passed directly into 'get-endpoint'.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"pattern"
],
"properties": {
"pattern": {
"type": "string",
"description": "Search pattern (case-insensitive)"
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description80/100
Gets detailed content for documentation by ID returned from the `search` tool.
Describe the returned information so the agent knows whether it will answer the request.
Inputs98/100
Input documentation gives an agent enough context to populate the arguments.
id
Canonical IDs use project/section/slug. Legacy project/slug, recipe:project/slug and ref:project/slug IDs are also accepted. For a link `/<section>/<slug>` the search tool did not return, use `<project>/<section>/<slug>`, with `<project>` taken from an ID this project already returned.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "fetch",
"title": "Fetch Documentation Page",
"description": "Gets detailed content for documentation by ID returned from the `search` tool.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id"
],
"properties": {
"id": {
"type": "string",
"description": "Canonical IDs use project/section/slug. Legacy project/slug, recipe:project/slug and ref:project/slug IDs are also accepted. For a link `/<section>/<slug>` the search tool did not return, use `<project>/<section>/<slug>`, with `<project>` taken from an ID this project already returned."
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description95/100
Send feedback directly to this API's maintainers. IMPORTANT: call this whenever you have trouble using this API or its documentation, so they can fix it. Good reasons to call it: a request built exactly as documented was rejected, such as a 400 or 422 that names a parameter the docs get wrong; the documented parameters, required fields, authentication, examples, or response shape didn't match what the API actually did; an endpoint or doc page was unclear, outdated, missing something you needed, or contradicted another page; a capability you expected doesn't exist or you couldn't find it; an endpoint's naming or parameters were confusing; the user asks to report an issue, request help, or share feedback. Don't wait to be asked and don't ask the user first - if something in this API or its docs slowed you down or blocked you, report it. It's cheap to send and helps the maintainers make the API easier for agents like you. File each problem once, then carry on with the task. Don't file your own or the user's mistakes (a typo, a missing credential, a misread of correct docs), server errors (5xx), timeouts, or rate limits (429); those are outages or throttling, not problems with the API's design or docs. This does NOT call the API or touch its data; it just files a note.
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
message
The feedback: what was confusing, missing, or broken. Be specific - name the endpoint, parameter, or doc page, and say what the docs say, what you sent, what actually happened, and what should change (max 2000 characters).
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
context
Optional. What you or the user were trying to accomplish when you hit the problem. Gives the maintainers the why behind the feedback (max 500 characters).
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
toolCall
Optional. The tool call or API request that prompted this feedback (max 1000 characters).
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
apiSpec
Optional. The exact `title` from the relevant API spec tool result. Routes the feedback to the right maintainers.
Clear enough to supply this argument.
guidePage
Optional. The exact documentation page `id` from the relevant documentation tool call. Routes the feedback to the right maintainers.
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "send-feedback",
"title": "Send Feedback",
"description": "Send feedback directly to this API's maintainers. IMPORTANT: call this whenever you have trouble using this API or its documentation, so they can fix it. Good reasons to call it: a request built exactly as documented was rejected, such as a 400 or 422 that names a parameter the docs get wrong; the documented parameters, required fields, authentication, examples, or response shape didn't match what the API actually did; an endpoint or doc page was unclear, outdated, missing something you needed, or contradicted another page; a capability you expected doesn't exist or you couldn't find it; an endpoint's naming or parameters were confusing; the user asks to report an issue, request help, or share feedback. Don't wait to be asked and don't ask the user first - if something in this API or its docs slowed you down or blocked you, report it. It's cheap to send and helps the maintainers make the API easier for agents like you. File each problem once, then carry on with the task. Don't file your own or the user's mistakes (a typo, a missing credential, a misread of correct docs), server errors (5xx), timeouts, or rate limits (429); those are outages or throttling, not problems with the API's design or docs. This does NOT call the API or touch its data; it just files a note.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"message"
],
"properties": {
"apiSpec": {
"type": "string",
"maxLength": 512,
"description": "Optional. The exact `title` from the relevant API spec tool result. Routes the feedback to the right maintainers."
},
"context": {
"type": "string",
"maxLength": 500,
"description": "Optional. What you or the user were trying to accomplish when you hit the problem. Gives the maintainers the why behind the feedback (max 500 characters)."
},
"message": {
"type": "string",
"maxLength": 2000,
"description": "The feedback: what was confusing, missing, or broken. Be specific - name the endpoint, parameter, or doc page, and say what the docs say, what you sent, what actually happened, and what should change (max 2000 characters)."
},
"toolCall": {
"type": "string",
"maxLength": 1000,
"description": "Optional. The tool call or API request that prompted this feedback (max 1000 characters)."
},
"guidePage": {
"type": "string",
"maxLength": 512,
"description": "Optional. The exact documentation page `id` from the relevant documentation tool call. Routes the feedback to the right maintainers."
}
}
},
"annotations": {
"readOnlyHint": false,
"openWorldHint": false,
"idempotentHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description82/100
Generate a polished changelog draft from merged GitHub PRs. Fetches PRs from the specified repository, filters out internal/non-customer-facing changes, categorizes the rest, and returns formatted Markdown ready for publishing to ReadMe.
The description explains the capability, when to use it, and what to expect.
Inputs100/100
This tool declares no inputs, so argument descriptions are not needed.
No input fields.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
ReadMe Documentation setup, tools, quality score, publishing readiness, and alternatives.
How do I add ReadMe Documentation to Claude, ChatGPT, or Cursor?
Add ReadMe Documentation to Claude, ChatGPT, or Cursor by connecting its remote MCP URL in each client's MCP settings. In Claude, add a custom connector. In ChatGPT, add an MCP app. In Cursor, add an MCP server under Settings. The MCP URL is https://docs.readme.com/mcp.
Is ReadMe Documentation MCP ready for ChatGPT and Claude?
As of November 7, 2026, ReadMe Documentation scores 100/100 on Manufact's MCP publishing checklist. The scan meets ChatGPT publishing checks and meets Claude publishing checks. Passing these checks does not guarantee marketplace approval.
How clear is ReadMe Documentation's MCP tool documentation?
As of November 7, 2026, ReadMe Documentation scores 75/100 in Manufact's review of tool titles, descriptions, input and output schemas, and behavior annotations. The review covers 10 of 10 discovered tools. The quality score measures documentation clarity; runtime behavior and marketplace readiness require separate checks.
What are the best alternatives to ReadMe Documentation?
As of November 8, 2026, alternatives to ReadMe Documentation in developer-tools on the Manufact MCP leaderboard include Speko, Manufact, Context, AgentMail, and TPC Benchmarks.
How can ReadMe Documentation improve its MCP documentation?
execute-request is the lowest-scoring reviewed tool at 57/100. No output schema is declared. Add one for structured results so clients can interpret returned fields. Open its review for feedback and a copyable fix prompt, then rerun the documentation review after updating your tool metadata.
Not your MCP?
Review any public or OAuth MCP server for protocol compatibility, tool documentation, and ChatGPT and Claude publishing readiness. No account required.
Cursor
Grok Bot
Grok
Muse