angi-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| angi_search_prosA | Find home-service pros on Angi for a trade in a US city. Returns each pro with ratings (overall plus per-dimension: quality, value, punctuality, professionalism, responsiveness), review count, percent-recommended, years in business, service area and amenities. |
| angi_get_proA | Read one Angi pro's full profile: business details, service area, hours, amenities, awards, tasks offered, contact address, and the ratings breakdown. Also reports how many reviews the page carries (fetch them with angi_get_reviews). |
| angi_get_reviewsA | Read the reviews on an Angi pro's profile page: rating, body text, reported job cost, date, service categories, verification flag, and the pro's public response where one exists. Filter by rating to isolate complaints or praise. |
| angi_list_tradesA | List every trade slug Angi publishes (~312, e.g. "plumbing", "air-duct-cleaning", "basement-waterproofing"). Call this to resolve a free-text trade to the slug angi_search_pros needs. Reads Angi's public sitemap directly — no browser bridge required. |
| angi_list_citiesA | List every US state/city that Angi publishes pages for, for one trade. Use it to confirm a city slug exists before searching, or to discover nearby cities. Reads Angi's public sitemap directly — no browser bridge required. |
| angi_get_accountA | The signed-in Angi user: first name, email address, user/entity ids, unread message count, and how many open and closed projects they have. Requires the browser tab to be signed in. |
| angi_list_my_projectsA | The signed-in user's Angi projects (service requests and bookings), open and closed. Records are returned exactly as Angi sends them — the response sets |
| angi_list_my_reviewsA | Reviews the signed-in user has written, plus pros Angi is prompting them to rate ( |
| angi_healthcheckA | Round-trips a small public www.angi.com URL (/robots.txt) through ContextMint Bridge (your signed-in browser tab) and returns diagnostics: the bridge's role (host/peer/null), port, version, the extension link (linked / pair pending / not attached / never answered), the elapsed round-trip time, and a plain-English hint distinguishing 'bridge never came up' from 'extension not connected' from 'this browser can't serve a capability' from 'real www.angi.com-side problem'. Read-only, no auth required. Call this when a real tool fails and you want to know which hop broke. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct resource+action: list_trades/list_cities resolve slugs, search_pros finds pros, get_pro/get_reviews read one pro, list_my_reviews/list_my_projects read the signed-in user's data, get_account reads identity, and healthcheck diagnoses hops. The potentially confusable pair (list_my_reviews vs get_reviews) is clearly separated by 'signed-in user's own reviews' vs 'reviews on a pro's page'. No two tools appear to do the same thing.
Uniform angi_ prefix with consistent snake_case verb_noun structure (list_, get_, search_) throughout. The one-word healthcheck is a trivial deviation and still fits the prefix pattern.
Nine tools is well-scoped for a read-oriented Angi browsing server, with each tool earning its place (slug resolvers, search/get pairs, user data, diagnostics). No redundant or filler tools.
Covers the core read surface (search pros, pro detail, reviews, trades, cities, account, projects) but has notable gaps: no way to read the messages whose unread count is reported, and no create/submit operation for service requests or projects despite listing them. Read-only design is coherent, but the lifecycle is incomplete.