Your MCP Server Scores 60/100 on Smithery: What It Means and How to Hit 100

What Is Smithery and Why Your Score Matters

Smithery is the primary directory for Model Context Protocol servers. When developers want to extend Claude Desktop, Cursor, Windsurf, or any MCP-compatible agent runtime with new capabilities, Smithery is where they look first. It lists hundreds of servers, supports one-click installation, and ranks results by a quality score.

That score is not cosmetic. It directly determines where your server appears in search results, whether it gets featured in curated lists, and whether developers trust it enough to wire it into their AI workflows. A server sitting at 60/100 is functional — but largely invisible to the developers who could use it.

The Anatomy of a 60/100 Score

Smithery's evaluation runs across several dimensions. A server at 60 typically has the basics covered — it installs, it runs, it exposes tools — but it's missing everything that makes it trustworthy and evaluable at a glance.

Here's what a 60/100 profile looks like in practice:

Category	Status at 60
Tool schemas	Present but thin — missing `description`, or detailed `inputSchema` per parameter
Server description	Empty or a vague one-liner
System prompt	Not defined
Package metadata	`name` and `version` set, but no `keywords`, `homepage`, `repository`, or `license`
README	Missing or a stub with no structured sections
Compatibility declaration	Transport registered but not explicitly declared

The server runs. Everything else that helps a developer evaluate it in 30 seconds is missing.

Why a Good Smithery Score Matters for Adoption

The practical impact is layered.

Discovery. Your Smithery score MCP ranking directly influences where you appear in directory searches. A server at 60 gets pushed below servers at 85+ for identical queries. Developers searching "email automation MCP" will find your competitor first.

Trust signal. A server with no description, no README, and no license reads as abandoned. The score is a visible proxy for "is this maintained?" — and developers make that decision in seconds.

Client integration quality. Claude Desktop, Cursor, and Windsurf read tool descriptions and the server system prompt at runtime. A tool with no description forces the model to guess what it does, which leads to incorrect invocations and poor user experience. The model's behavior is only as good as the metadata you provide.

The installation wizard. Smithery's one-click installer surfaces your README and smithery.yaml directly in its UI. An empty README means the wizard shows nothing. A structured one walks the developer through setup without them leaving the page.

The MCP specification explicitly recommends rich tool descriptions as a protocol-level best practice. Smithery operationalizes this recommendation as a numeric score.

Checklist: From 60 to 100 on Smithery

1. Add `description` and full `inputSchema` to every tool

This is the highest-leverage change. In the TypeScript SDK, every tool registration accepts a full schema object. Write descriptions for the model, not for humans — be specific about what the tool returns, not just what it does.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({
  name: "my-email-server",
  version: "1.0.0",
});

server.tool(
  "create_inbox",
  {
    description:
      "Create a temporary email inbox for a target service. Returns the inbox address, inbox ID, and expiry timestamp.",
    inputSchema: {
      service_name: z
        .string()
        .describe(
          "The service this inbox is for (e.g. 'GitHub', 'Stripe'). Used to label the inbox."
        ),
      ttl_minutes: z
        .number()
        .optional()
        .describe(
          "Inbox lifetime in minutes. Defaults to 30 if not specified. Max value depends on your plan."
        ),
    },
  },
  async ({ service_name, ttl_minutes }) => {
    // implementation
  }
);

Every description field is injected into the model's context. If it's vague, the model will call your tool incorrectly.

2. Define a server-level system prompt

The system prompt is sent to the model when the server is active. Without it, the model has no context about what your server is for or when to use its tools.

const server = new McpServer({
  name: "my-email-server",
  version: "1.0.0",
  description:
    "Programmable temporary email inboxes for AI agent workflows. Use this server to create disposable inboxes, wait for verification emails, extract OTP codes, and complete signup flows without human intervention.",
});

Keep it concise and action-oriented: what the server does, what workflows it enables, and when the agent should reach for it.

3. Complete your package metadata

Smithery reads your npm or PyPI package metadata. Every missing field is a deduction:

{
  "name": "@yourscope/my-email-server",
  "version": "1.0.0",
  "description": "Programmable temporary email inboxes for AI agents via MCP",
  "keywords": ["mcp", "email", "temporary-email", "ai-agents", "automation"],
  "homepage": "https://yourservice.com",
  "repository": {
    "type": "git",
    "url": "https://github.com/yourhandle/my-email-server"
  },
  "license": "MIT"
}

The keywords array is how Smithery categorizes your server. Always include mcp as one keyword. Add domain-specific terms developers would actually search for — email, automation, database, git, etc.

4. Add a structured README

Smithery renders your README inside its UI. Use this minimum structure:

# my-email-server

Programmable temporary email inboxes for AI agents via Model Context Protocol.

## Tools

| Tool | Description |
|---|---|
| `create_inbox` | Create a disposable inbox with a configurable TTL |
| `wait_for_email` | Poll until a verification email arrives |
| `extract_otp` | Parse a numeric OTP code from an email body |

## Installation

### Claude Desktop

Add to `~/Library/Application Support/Claude/claude_desktop_config.json`:

```json
{
  "mcpServers": {
    "my-email-server": {
      "command": "npx",
      "args": ["-y", "@yourscope/my-email-server"],
      "env": { "API_KEY": "your_key_here" }
    }
  }
}
```

### Smithery

[Install via Smithery](https://smithery.ai/server/@yourscope/my-email-server)

## Usage

...

Three sections are what Smithery checks: Tools, Installation, Usage. If those three exist with real content, the README score is covered.

5. Publish to npm with `--access public` and semver

npm publish --access public

If your package is scoped (@yourscope/), --access public is required — scoped packages default to private. Version with semver: 1.0.0 for stable releases, 0.x.y during development. A package stuck at 0.0.1 with no changelog signals "early prototype" to both Smithery and developers.

6. Add `smithery.yaml`

If Smithery can't infer your server's configuration from the package, add a smithery.yaml at the repo root:

startCommand:
  type: stdio
  configSchema:
    type: object
    required:
      - apiKey
    properties:
      apiKey:
        type: string
        description: Your API key from the service dashboard
  commandFunction: |-
    (config) => ({
      command: "npx",
      args: ["-y", "@yourscope/my-email-server"],
      env: { API_KEY: config.apiKey }
    })

This file enables the Smithery installation wizard — the one-click flow that drops a pre-configured snippet directly into the user's Claude Desktop config. Without it, the wizard may fail silently and the developer has to configure the server manually.

Real Case: uncorreotemporal.com

uncorreotemporal.com runs a Python MCP server in production — uncorreotemporal-mcp — built with FastMCP. At the time of writing it holds a 100/100 on Smithery, and its implementation shows what a well-structured listing looks like in practice.

The server exposes six tools, each covering a distinct step in an email automation workflow:

create_signup_inbox — creates a temporary inbox for a named service
wait_for_verification_email — polls until a matching email arrives (with subject/sender filters)
get_latest_email — reads the full content of the most recent message
extract_otp_code — parses a 4–8 digit OTP from an email body or message reference
extract_verification_link — extracts the most likely verification URL with optional domain filtering
complete_signup_flow — end-to-end helper that chains inbox creation, polling, and extraction in a single call

Each tool carries a description written from the model's perspective. The pyproject.toml includes name, description, keywords (["mcp", "email", "temporary-email", "ai-agent", "automation"]), license, homepage, and repository. Three transports are declared: stdio, streamable-http, and sse — covering both local subprocess and networked deployments.

The key pattern: tool descriptions read like agent instructions, not function signatures. That distinction is what separates a 60 from a 100 on Smithery, and it's what determines whether the model calls your tool correctly in the first place.

Check Your Score and Act

Go to https://smithery.ai/server/<your-package-name> right now. If you see anything below 85, the checklist above covers every deduction point. The three fastest wins:

Add description to every tool — 5–10 minutes per tool, highest score impact
Complete package metadata — 10 minutes, covers multiple categories at once
Add smithery.yaml — 15 minutes, unlocks the installation wizard

If you're building agent workflows that need programmable email — inbox creation, OTP extraction, verification link parsing — the server at uncorreotemporal.com covers all of it with a single MCP integration. Connect it to Claude Desktop or Cursor in minutes, and your agents can complete signup flows and email verification steps without any human involvement.