MCP server ideas: 12 servers worth building, with the tools each one exposes

01 Read-only Postgres inspector

Lets an assistant look at your schema and run safe SELECT queries so it can answer data questions without you pasting rows.

Tools

list_tables, describe_table, run_select (row limit, timeout).

Resource

The schema as a text resource.

Transport

stdio, on your machine.

Risk

A query that reads too much or runs too long.

The point is restraint. Connect with a database role that can only SELECT, add a statement timeout and cap rows at 200. A prompt that says read only is not protection; the role is. Return the column names and types with every result so the assistant stops guessing at them.

First version: three tools, one connection string read from the environment, results as a compact table. Extension: a tool that explains a query plan, and a resource listing the tables with a one-line description you write. Write tests for the guard: an INSERT, a multi-statement string and a ten-minute query must each be refused.

Build an MCP server in TypeScript over stdio.
User: a developer who wants an assistant to answer data questions.
Tools: list_tables (no input), describe_table (table name), run_select (sql string).
Rules: connect with the DATABASE_URL environment variable, which holds a role limited to SELECT. run_select rejects anything that is not one SELECT statement, sets a 5 second statement timeout and returns at most 200 rows with column names.
Logging: stderr only, never stdout.
Do not build: write tools, HTTP transport, authentication.
Done when: an INSERT, a SELECT 1; DROP TABLE x; and a 30 second pg_sleep are each refused with a clear error, and a normal SELECT returns rows.

02 Environment difference between two deploys

Compares the environment variable names, and whether they changed, between the deploy that worked and the one that did not.

Tools

list_deploys, diff_env (deploy A, deploy B), get_deploy_log_tail.

Resource

None.

Transport

stdio.

Risk

Leaking secret values into the conversation.

A post on the board asks which env var changed between the deploy that worked and the one that did not. The tool design question is secrets. Return names and a changed, added or removed flag, and a hash prefix for values, never the values themselves. The assistant can then say that DATABASE_URL changed without ever seeing it. See the idea.

First version: read two exported env files, since a file works with any host. Extension: call your host's API to list deploys. Test the redaction by feeding in a fake secret and searching the output for it.

Read “Environment difference between two deploys” on the board and copy its build prompt →

03 Error-log triage for a small app

Groups the last day of errors by cause and lets the assistant pull the surrounding lines for one group.

Tools

search_logs (query, since), group_errors (since), get_context (error id, lines).

Resource

Optional: the runbook as text.

Transport

stdio over local log files.

Risk

Personal data inside log lines.

Grouping is the value. An assistant given 4,000 raw lines wastes its context, but given 12 groups with a count and one sample each it can reason. Group by the message with numbers, IDs and timestamps replaced by placeholders.

First version: read a log file or folder, group, return the top ten. Extension: a tool that shows what changed in the code near the first occurrence, using git. Add a redaction step for emails and tokens before anything leaves the server, and test it with a log line that contains both.

04 Feature-flag lookup and change with confirmation

Reads which flags are on for which environment and can propose a change that a person must approve.

Tools

list_flags, get_flag, propose_flag_change.

Resource

Flag naming rules.

Transport

stdio first.

Risk

A production flag flipped by a misunderstood sentence.

Split read and write. The read tools are open. The write tool does not write: it records a proposal and returns a summary and an ID, and a person applies it in your flag dashboard or with a command. That keeps the human in the loop the spec asks for, without relying on the client's confirmation dialog alone.

First version: flags in a JSON file, three tools. Extension: connect to your flag service and show who changed each flag last. Test that propose_flag_change leaves the file untouched.

01 Handbook server that says when it does not know

Searches your team handbook and returns passages with their file names, and returns a fixed not-found reply when nothing matches.

Tools

search_handbook (query), read_page (path).

Resources

Each handbook page, by file path.

Prompts

/answer-from-handbook.

Risk

Plausible answers from near-miss passages.

A post on the board describes an agent that answers from your docs and stays quiet otherwise. As an MCP server the design is cleaner: the server never writes an answer, it returns passages and a score, and a not-found reply when the score is low. The assistant does the wording. See the idea.

This one uses all three primitives. Resources expose pages for attaching, the tool searches, and a prompt template lets a person pick Answer from handbook. First version: Markdown files in a folder, keyword search. Extension: embeddings. Test with ten questions you wrote, five answerable and five not.

Read “Handbook server that says when it does not know” on the board and copy its build prompt →

02 CSV analyst for files you do not want to upload

Loads a CSV on your machine and answers questions with SQL, returning a result, never the file.

Tools

load_csv (path), describe_columns, query_sql.

Resource

None.

Transport

stdio, local only.

Risk

A wrong query returning a confident wrong total.

People paste spreadsheets into chats and hit size limits. A local server avoids both: the file stays put and the model sees only column names, sample rows and query results. Always return the row count with each result so a surprising number is easy to doubt.

First version: use an in-process SQL engine, one file at a time. Extension: joins across two files and a tool that returns the generated SQL so you can check it. Test with a file whose correct totals you computed by hand.

03 Invoice folder reader

Lists invoices in a folder, reads the text of one, and marks it paid in a small ledger after you confirm.

Tools

list_invoices, read_invoice (id), mark_paid (id, date).

Resource

The ledger as CSV.

Transport

stdio.

Risk

A destructive write on money records.

Mark mark_paid as not read-only, and make it idempotent, so calling it twice gives the same result. Keep the ledger append-only: a correction is a new line, not an edit. That means a wrong call is a bad line you can see and reverse, not a lost record.

First version: PDFs converted to text, the three tools, a CSV ledger. Extension: due-date warnings as a prompt. Test that two identical mark_paid calls leave one ledger line.

04 Pantry and shopping list server

Holds what is in your kitchen and lets an assistant plan dinners from it and build a shopping list for the gap.

Tools

pantry_list, pantry_add, pantry_use, shopping_list_for (recipe text).

Resource

The pantry as JSON.

Transport

stdio.

Risk

Low: the worst case is a wrong list.

A low-risk server is a good place to learn the protocol. The assistant already writes recipes. The missing piece is memory of what you own. shopping_list_for takes recipe text, subtracts the pantry and returns the gap with quantities.

First version: a JSON file, four tools, quantities in grams or units. Extension: expiry dates and a prompt called Use what is about to go off. Test unit mismatches: a recipe in cups against a pantry in grams should return a clear error, not a guess.

01 Accessibility audit for any URL

Runs an automated accessibility check on a page and explains each finding in plain language with the element involved.

Tools

audit_url (url), explain_violation (rule id), list_fixes (audit id).

Resource

The rule list.

Transport

stdio, headless browser local.

Risk

Pointing the browser at internal addresses.

Fetching arbitrary URLs from a server is a security problem. Refuse private addresses and local files, and limit to http and https. Mark the tool as open world, since it touches things outside your system, and as read-only.

First version: an open-source checker run in a headless browser, results grouped by severity, a cap of 50 findings. Extension: compare two audits to see what a deploy fixed or broke. Automated checks find only some problems, so say that in every result.

02 Transit timetable lookup

Answers next departures and disruptions for stops in one city from the public timetable feed.

Tools

find_stop (name), next_departures (stop id, count), disruptions (line).

Resource

None.

Transport

stdio; HTTP if you share it.

Risk

Stale data presented as live.

A chat assistant cannot tell you when the next tram leaves. A timetable server can, if your city publishes a feed. Return a fetched-at time with every answer so the assistant can say how fresh it is. Check the feed's license before you share the server.

First version: one city and one operator. Extension: a trip tool that chains two legs. Test that the fetched-at field is present and that a stop name with accents still resolves.

03 Time tracker as tools

Start and stop timers and get a weekly summary, all by talking to the assistant you already have open.

Tools

start_timer (project), stop_timer, summary (week).

Resource

Entries as CSV.

Transport

stdio.

Risk

Two timers running after a forgotten stop.

The assistant is the interface. The server enforces the rules: one timer at a time, an entry never in the future, and a stop with no start returns an error the assistant can explain. Put the rules in code, not in a prompt.

First version: three tools and a CSV. Extension: a tool that finds gaps in the day. Test the double-start case first.

04 Team playbook server built on prompts

Exposes your team's reusable instructions, such as review checklists and incident updates, as prompts people pick by name.

Prompts

review_pr, write_changelog, incident_update.

Resources

Style guide, severity scale.

Tools

None needed.

Risk

Instructions drifting out of date.

Prompts are the least used primitive and the best fit for a team. The spec describes them as user-controlled: exposed so a person can pick one explicitly, typically through a slash command. A playbook server turns a wiki page nobody reads into a command everybody can run.

First version: three prompts reading from Markdown files in a git repository, so changing the playbook is a pull request. Extension: arguments, such as a ticket ID. Over HTTP, add authorization before the whole team connects. Test that each prompt returns the current file text, not a cached copy.