Make your MCP tools complete

What we checked

Tool Coverage is the deterministic counterpart to the AI-judged clarity score. Every number below is computed directly from the tools your server exposes, so it is fully reproducible, no model opinion involved:

Why it matters

An agent picks and calls your tools from their definitions alone. Three things make that surface predictable:

• Descriptions. A tool with no description is a coin flip for the model. We measure the fraction of tools carrying a real, non-boilerplate description.
• Parameter docs. Every parameter that takes a value needs to say what that value is. We measure the fraction of declared parameters that carry a description (tools that take no arguments are excluded, not penalised).
• Structured output. Declaring an outputSchema lets a model parse your result reliably instead of scraping free text. This is credit-only: it is an optional feature, so not declaring one never lowers your score.

How to fix it

Describe each tool and each parameter, and declare an output schema where your tool returns structured data. A consistent naming convention and shared verb vocabulary (create_, list_, delete_) are good practice for helping agents predict your surface, but they are not scored here. The example below describes every tool and parameter and declares its output shape.

// @modelcontextprotocol/sdk - a described tool, described params,
// and a declared output schema.
import { z } from "zod";

server.registerTool(
"create_invoice",
{
  description: "Create an invoice for a customer and return the stored record.",
  inputSchema: {
    customer: z.string().describe("Customer name or ID to bill."),
    amount_cents: z.number().int().describe("Total to charge, in cents."),
  },
  // Declaring outputSchema is credit-only in the score, and lets the model
  // parse the result instead of guessing at free text.
  outputSchema: {
    id: z.string().describe("The stored invoice ID."),
    status: z.enum(["draft", "open"]).describe("Lifecycle status."),
  },
},
handler,
);

// Naming and verb consistency (create_invoice, list_invoices, delete_invoice)
// isn't scored, but it's still good practice: it helps agents predict tools
// they haven't seen yet.

# Official 'mcp' SDK (FastMCP) - the docstring is the description; typed,
# described fields are the parameter schema; a return model gives outputSchema.
# (Naming convention isn't scored, but a consistent one is still good practice.)
from pydantic import BaseModel, Field
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-server")

class Invoice(BaseModel):
  id: str = Field(description="The stored invoice ID.")
  status: str = Field(description="Lifecycle status.")

@mcp.tool()
def create_invoice(
  customer: str = Field(description="Customer name or ID to bill."),
  amount_cents: int = Field(description="Total to charge, in cents."),
) -> Invoice:
  """Create an invoice for a customer and return the stored record."""
  ...

# A consistent verb vocabulary across the surface (create_invoice,
# list_invoices, delete_invoice) isn't scored, but helps agents predict
# a tool they haven't seen yet.

How we re-check

We re-read your tools on the next capture: a crawl for a hosted endpoint, or a fresh sandbox run of your published package. As description coverage rises, more parameters get documented, and output schemas appear, the tool-coverage signals improve on the following score refresh.

Give this to your AI

Paste this into Claude Code (or any coding agent) from inside your server's repository. It states the failing signal, the outcome we re-check for, and the format the fix has to take.

Context: this repository publishes an MCP server, either as a hosted
endpoint or as a package on a registry such as npm or PyPI.
VerifyMCP's tool coverage check failed, which means some tools lack a
real description, or some parameters that take a value are undocumented.

Goal: every tool carries a genuine, non-boilerplate description, every
value-taking parameter is described, and structured tools declare an
`outputSchema`, so the next capture records description and parameter-doc
coverage at full marks.

Do this:
1. List every tool and check its `description` field is real prose, not
   empty or a copy of the tool name.
2. Add a `description` to every parameter that takes a value (skip
   parameter-less tools, they are excluded from this check anyway).
3. Where a tool returns structured data, declare an `outputSchema` for
   it (optional, credit-only, never lowers the score if omitted).

Rules:
- Descriptions must genuinely explain what the tool does; do not write
  generic filler just to satisfy the description-coverage count.

Report back: description and parameter-doc coverage before and after.

Reference: https://verifymcp.io/docs/remote/tool-quality