angi-mcp

by chrischall

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: pro profiles, pro search, reviews, trade/city reference lists, user account, user projects, user reviews, and a health check. There is no overlap or ambiguity between the public data tools and the user-specific tools.
Naming Consistency4/5
All tools share the 'angi_' prefix, and most follow a verb_noun pattern (get_pro, search_pros, list_trades, get_account, etc.). The lone exception is 'angi_healthcheck', which is a compound noun rather than a verb phrase, creating a minor inconsistency.
Tool Count5/5
9 tools is well within the ideal 3-15 range and covers both public Angi data and authenticated user data without feeling bloated. Each tool serves a clear purpose, and the count is appropriate for a domain-specific MCP server.
Completeness3/5
The server covers the main read workflows for pros, reviews, trades, cities, and user data, but has notable gaps: the account tool reports unread message count with no tool to fetch messages, and there are no write operations (e.g., create project, send message) even though user projects are listed. This creates a dead end for user account actions.
Average 4.5/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 32 commits in the last 12 weeks
- Last stable release on September 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds value by disclosing that records pass through raw and the response sets recordFieldsVerified: false. This goes beyond the structured annotations and gives operational context, though it does not explain the implication of that flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the primary function and then adding a clarified caveat. Every sentence contributes meaning, and the caveat is explained inline rather than left ambiguous. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool with no output schema, the description covers the return structure (reviews + unratedPros) and a critical behavioral detail (recordFieldsVerified: false). This is complete for the tool's complexity and does not over-promise or omit necessary caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. The description adds no parameter details because none exist, but it does describe the output structure (reviews and unratedPros), which is helpful given the absent output schema and parameter need.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns reviews written by the signed-in user plus unrated pros, using a specific verb ('Reviews') and resource ('signed-in user' reviews). This distinguishes it from siblings like angi_get_reviews, which likely target other reviewers or pros.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for the signed-in user's own reviews and mentions a shared caveat with projects, but it does not explicitly state when to use this tool versus alternatives such as angi_get_reviews or list_my_projects. No exclusion or alternative is named, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent hints, and the description adds useful context: it reads Angi's public sitemap directly and requires no browser bridge, which helps an agent understand operational constraints. It does not detail the return format, but for a simple list operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose with examples, usage guidance naming the downstream tool, and a relevant implementation detail. Front-loaded with the action verb and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only list tool with full schema annotations, the description covers what it returns (list of slugs), how to use it, and a practical scenario. The mention of 'no browser bridge required' preempts environment questions. Given annotations provide safety guarantees and the schema covers the filter, the description is complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'contains' is fully documented in the schema with a clear case-insensitive substring filter example. The description does not add parameter-level detail beyond the schema, but with 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List every trade slug Angi publishes,' including a count and concrete examples. It also distinguishes the tool from siblings by stating it resolves free-text trades to the slug needed by angi_search_pros, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'Call this to resolve a free-text trade to the slug angi_search_pros needs.' This names a related sibling and a clear prerequisite, though it does not articulate when not to use it or offer alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds value by detailing exactly what data is returned (rating, body text, job cost, date, categories, etc.) and notes the conditional inclusion of the pro's public response 'where one exists.' This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word adds value. It efficiently covers both what is returned and how to filter, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with strong annotations and a well-described schema, the description is quite complete. It lists the return fields and filtering capability but does not mention pagination, ordering, or default limit behavior. Still, it provides enough for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description augments this by explaining the intent of rating filters ('use maxRating: 3 to surface complaints' appears in schema, but the description's 'isolate complaints or praise' reinforces the use case). This adds meaning beyond the bare parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read the reviews on an Angi pro's profile page' and enumerates the specific data fields. This distinguishes it from sibling tools like angi_search_pros (search) and angi_get_pro (pro details) by explicitly focusing on reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a pro's profile URL and want their reviews. It also gives a concrete use case ('Filter by rating to isolate complaints or praise'), but it does not explicitly name alternatives or state when not to use the tool. The context is clear though.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description doesn't need to repeat those. It adds valuable behavioral context: 'Reads Angi's public sitemap directly — no browser bridge required,' revealing the data source and mechanism, which is beyond the annotations and helps set expectations about speed and dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause earns its place. It states the purpose, adds usage guidance, and notes a key implementation detail without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, and data source, which is solid for a read-only list tool. There is no output schema, so explaining return values isn't strictly required, but the description could hint at the output structure (e.g., list of slugs) or note if the result might be large. Still, the given details are sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already documented (trade, state, contains). The description reinforces that 'trade' is the required scope ('for one trade') and implies slug usage, but adds little beyond what the schema provides. Baseline 3 is appropriate as the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List every US state/city that Angi publishes pages for, for one trade.' It uses a specific verb ('List') with a clear resource ('US state/city') and scope ('for one trade'), distinguishing it from sibling tools like angi_list_trades which lists trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use it to confirm a city slug exists before searching, or to discover nearby cities.' This provides concrete guidance on appropriate contexts and implies an alternative (searching) where this tool is a prerequisite, going beyond generic instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is known. The description adds meaningful behavioral context by specifying the authentication requirement (signed-in tab) and the exact data fields returned, which goes beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the key information ('The signed-in Angi user') and then lists the returned fields. There is no redundancy or filler; every phrase contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, read-only tool with rich annotations, the description fully covers the essential information: what the tool returns and the authentication prerequisite. No output schema exists, but the description sufficiently explains the return contents. There are no missing aspects given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema (empty object) fully covers this. With no parameters to describe, the description appropriately focuses on the return value. Per the rubric, a baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the signed-in Angi user's first name, IDs, unread message count, and open/closed project counts. It uses a specific resource ('the signed-in Angi user') and differentiates from sibling tools like angi_get_pro and angi_search_pros, which focus on pros.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when needing current user account information. It also notes the prerequisite that the browser tab must be signed in. However, it does not explicitly mention alternatives or exclude other tools, though the sibling list makes the distinction apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, and idempotent behavior. The description adds value by detailing what the profile includes (ratings breakdown, contact address, awards, etc.) and that it reports the review count but not the reviews themselves. This provides context beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every element adds value, and the structured list of profile contents is efficient. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, a schema describing both params, and a clear read-only purpose, the description fully covers what the agent needs: what the tool returns, how to interpret the profileUrl, and how to fetch reviews separately. No output schema is needed because the description enumerates the returned fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with detailed descriptions, including the profileUrl format and the compact flag. The tool description does not add parameter-level semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Read one Angi pro's full profile', then enumerates the specific fields (business details, service area, hours, etc.). It also distinguishes from siblings by explicitly pointing to angi_get_reviews for fetching reviews, making the tool's unique role obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that reviews should be fetched with angi_get_reviews, providing a direct alternative for a specific need. It also implies that this tool is for the full profile, and the phrase 'full profile' clarifies the scope relative to search (angi_search_pros). This is clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent), the description discloses that records are returned raw as Angi sends them and that recordFieldsVerified is false because no populated project has been observed. This provides crucial, non-obvious behavioral context about field reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, the second provides an important caveat. It is concise, front-loaded, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter, the description covers what is returned, the scope, and a behavioral warning about field verification. The lack of an output schema is compensated by the note that field names should be read from data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single 'status' parameter with its enum and default. The description adds no additional parameter-level detail, so the baseline score of 3 (high schema coverage) applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the signed-in user's Angi projects (service requests and bookings), both open and closed. This is a specific verb+resource combination that distinguishes it from sibling tools like angi_search_pros and angi_list_my_reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for fetching the current user's projects, which is distinct from searching or listing other resources. However, it does not explicitly mention alternatives or when not to use it, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as readOnly and idempotent, but the description adds substantial behavior context: return fields (ratings, review count, percent-recommended, years in business), pagination behavior (10 per page), slug requirements, and the absence of zip-code filtering. This is far beyond annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five focused sentences: purpose first, then return details, usage prerequisites, pagination, and a critical limitation. Every sentence adds distinct value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the exact returned fields including per-dimension ratings, review count, percent-recommended, years in business, service area, and amenities. It also covers pagination, prerequisite slug resolution, and the location limitation, making it complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters (100% coverage), so baseline is 3. The description adds meaning by clarifying that trade and city are Angi slugs requiring resolution, and explains page is used to walk through results at 10 per page, providing value beyond the property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Find', identifies the resource as 'home-service pros on Angi', and scopes it to 'a trade in a US city'. This clearly distinguishes it from siblings like angi_get_pro (single pro) and angi_get_reviews (reviews).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs resolving trade and city slugs with angi_list_trades and angi_list_cities first, and notes the zip-code filter limitation. It does not explicitly contrast with alternatives like angi_get_pro for single-pro lookups, but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, but the description add significant behavioral context: it performs a round-trip to a public URL, returns specific diagnostics (role, port, version, elapsed time), and interprets failure modes. This goes well beyond what annotations alone provide, and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first explains what it does and what it returns, second gives usage context. It is front-loaded with action, every detail is relevant, and no words are wasted. It is concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description thoroughly covers what the tool does, what it returns, and when to use it. It even explains how to interpret the output ('distinguishing bridge never came up from extension not connected from www.angi.com-side problem'). No gaps remain for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds meaning by specifying the fixed URL used (/robots.txt), which is not a parameter but explains the tool's input implicitly. Without parameters, no further parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('round-trips'), specific resource ('small public www.angi.com URL /robots.txt'), and purpose (diagnostics for fetchproxy bridge). It distinguishes itself from all sibling tools by being a healthcheck/diagnostic tool, not a data-fetching tool. The conditional 'Call this when a real tool fails' further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'Call this when a real tool fails and you want to know which hop broke.' This gives a clear trigger condition. It also adds 'Read-only, no auth required,' which indicates it's safe to try. No alternative tools are relevant, but the conditional usage is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![angi-mcp MCP server](https://glama.ai/mcp/servers/chrischall/angi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/angi-mcp)

Score Badge

Copy to your README.md:

[![angi-mcp MCP server](https://glama.ai/mcp/servers/chrischall/angi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/angi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/angi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server