Maango-mcp

Name: Maango-mcp
Author: maango-io

Official

by maango-io

Overview Schema Related Servers Score Discussions

Python

Hybrid

Maango MCP Server

License: MIT Python 3.10+ Docker (GHCR)

The permissions layer for AI agents on the web. Before your agent scrapes, summarises, trains on, or otherwise uses content from a website, ask Maango what's allowed. One call, canonical answer.

Why

Every site that publishes a robots.txt, ai.txt, llms.txt, TDM-Rep header, or AI-specific ToS clause is telling agents what they can and can't do. Today no one parses all eight standards. NYT, Reddit, and Stack Overflow are suing over training data; the EU AI Act now requires opt-out compliance. Building this gate from scratch is weeks of work per agent.

Maango aggregates 1,000,000+ domains × 8 AI-policy standards into one canonical answer. Your agent calls check_permission(domain, action) and gets back allowed: true/false + a structured reason. That's it.

Hosted endpoint: https://mcp.maango.io/sse (free, no key required)
Protocol: Model Context Protocol
Registry coverage: 1,000,000+ domains, 8 AI-policy standards aggregated
Transports: stdio (local), sse + streamable-http (remote)
Image: ghcr.io/maango-io/maango-mcp
Package: pip install maango-mcp

Related MCP server: blackwall-mcp

Tools exposed

Tool	What it does
`check_permission(domain, action, agent_id?)`	Decide in one call whether an action is allowed. Returns `allowed` + reason code + explanation + stance + signals.
`lookup_domain(domain)`	Summary of a domain's AI policy — stance, use-cases, bots, signals.
`lookup_domain_full(domain)`	Full raw policy data including robots.txt, ai.txt, llms.txt, TDM-Rep, meta tags.
`lookup_domain_conflicts(domain)`	Cross-signal conflicts (e.g. robots.txt vs ToS).
`search_domains(query, stance?, limit?, offset?)`	Prefix search the registry with optional stance filter.
`batch_check(domains[])`	Compare policies across 2–25 domains side by side.
`get_changelog(domain?, change_type?, limit?, offset?)`	Policy change history.

Reason codes returned by `check_permission`

compliant — action explicitly permitted
action_blocked — the specific use-case (training/search/ai_input) is blocked
bot_blocked — the named agent_id is on the domain's blocked-bots list
stance_blocks_all — domain blocks all AI access site-wide
no_policy — no policy on file; conservative default is deny
unspecified — action or use-case not addressed by the policy
lookup_error — registry could not be reached

Installation

Claude Desktop (remote, recommended)

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "maango": {
      "url": "https://mcp.maango.io/sse"
    }
  }
}

Restart Claude Desktop. Ask: "Check if I can scrape nytimes.com for training data."

Cursor

Settings → MCP → Add new MCP Server:

{
  "maango": {
    "url": "https://mcp.maango.io/sse"
  }
}

Cline / Zed / any MCP client

Point them at https://mcp.maango.io/sse. No auth required for the hosted endpoint.

Local development (stdio)

git clone https://github.com/maango-io/maango-mcp.git
cd maango-mcp
uv venv && source .venv/bin/activate
uv pip install -e .
cp .env.example .env          # optionally add MAANGO_API_KEY for higher rate limits
maango-mcp                    # runs with stdio transport

Then in Claude Desktop:

{
  "mcpServers": {
    "maango": {
      "command": "maango-mcp"
    }
  }
}

Self-hosting

Any platform that can run a Python HTTP service works. Quick Docker path:

docker build -t maango-mcp .
docker run -p 8000:8000 \
  -e MAANGO_API_KEY=maango_sk_xxx \
  -e MAANGO_MCP_TRANSPORT=sse \
  maango-mcp

Environment variables:

Var	Default	Purpose
`MAANGO_MCP_TRANSPORT`	`stdio`	`stdio` \| `sse` \| `streamable-http`
`MAANGO_MCP_HOST`	`0.0.0.0`	Bind address (remote transports only)
`MAANGO_MCP_PORT`	`8000`	Bind port (remote transports only)
`MAANGO_API_BASE_URL`	`https://api.maango.io`	Maango REST API base URL
`MAANGO_API_KEY`	(none)	Optional bearer token for higher rate limits

How it works

┌────────────────┐     MCP (sse/streamable-http)     ┌─────────────────┐
│ Claude Desktop │ ◄───────────────────────────────► │  mcp.maango.io  │
│  Cursor, …     │                                   │  (this server)  │
└────────────────┘                                   └────────┬────────┘
                                                              │ HTTPS
                                                              ▼
                                                     ┌─────────────────┐
                                                     │  api.maango.io  │
                                                     │  (REST, 1M      │
                                                     │   domains)      │
                                                     └─────────────────┘

The MCP server is a thin wrapper. The real data lives in the Maango REST API. We normalise the response into MCP-friendly tool output and handle the action → use-case mapping (e.g. "scrape" → training policy check).

Observability

The server exposes two HTTP endpoints when running on sse or streamable-http transports (not stdio — there's no port to bind):

GET /health — cheap liveness probe, no upstream call. Used by Docker HEALTHCHECK, nginx, and uptime monitors.
GET /metrics — Prometheus exposition. Tracks maango_mcp_tool_requests_total{tool,status} and maango_mcp_tool_duration_seconds{tool} (histogram).

Logs are emitted as one JSON object per stderr line with a per-tool-call req_id that propagates through the client and decision-tree. Pipe stderr to your log shipper of choice (Loki / Datadog / CloudWatch).

Development

See CONTRIBUTING.md for the full workflow. Quick start:

uv sync --extra dev
uv run pytest -q
uv run maango-mcp                                # stdio
MAANGO_MCP_TRANSPORT=sse uv run maango-mcp       # SSE on :8000

Security disclosures: see SECURITY.md.

Roadmap (not in v0.1)

Web Bot Auth signature verification
Capability-token issuance (Biscuits / Macaroons)
Payment-required flow via x402
Receipt IDs with tamper-evident Merkle proof
Real-time policy negotiation (Phase 3)

The roadmap is shaped by what users actually need — see Issues for the live list.

Contributing

If you find this useful:

⭐ Star the repo — that's how more agents find it.
🐛 Open an issue for bugs, missing domains, or anything in a tool's output that surprised you. Include the req_id from the JSON log line if you have it.
💡 Have a use case the current 7 tools don't cover? File an issue with a real example — that beats abstract feature requests every time.
🛠 PRs welcome — see CONTRIBUTING.md for the dev workflow and PR checklist.
🔒 Security disclosures: SECURITY.md. Email instead of opening an issue.

License

MIT — see LICENSE.

Available Tools

7 tools

batch_checkA

Compare AI policies across multiple domains using the Maango registry.

Looks up 2-25 domains at once and returns each domain's stance, use-case policies, and bot lists side-by-side.

Args: domains: List of 2-25 domains to compare (e.g. ["nytimes.com", "github.com"]).

ParametersJSON Schema

Name	Required	Description	Default
`domains`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. It states that it returns each domain's stance, use-case policies, and bot lists side-by-side, and also communicates the 2-25 domain constraint. Since this is a read-only lookup operation, the lack of side-effect warnings is acceptable, though it does not explicitly state read-only.

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 short paragraph followed by a well-structured Args block. It front-loads the primary purpose in the first sentence and uses minimal, high-value wording for the parameter explanation.

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 the single parameter and the presence of an output schema, the description provides sufficient context for an agent to select and invoke the tool correctly. The 2-25 range and example ensure valid input, and the return description clarifies what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only defines 'domains' as an array of strings, but the description's Args section adds crucial semantics: it defines the required count (2-25), provides a concrete example, and clarifies that the entries are domain names. This fully compensates for the 0% schema description coverage.

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 'Compare AI policies across multiple domains using the Maango registry', which clearly states the verb (compare), resource (AI policies), and scope (multiple domains). It also mentions the batch nature (2-25 domains) and differentiates from single-lookup siblings like lookup_domain.

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 the agent that this is for comparing 2-25 domains at once, making it obvious when to use it. However, it does not explicitly name alternatives like 'use lookup_domain for a single domain', so it lacks formal exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_permissionA

Check whether an AI agent is permitted to perform a specific action on a given domain.

Returns a structured compliance decision with allowed (bool), a reason code, a human-readable explanation, the domain's stance, and the signals that informed the answer. Use this before your agent scrapes, summarizes, trains, or searches content from a site.

Reason codes: compliant — action is explicitly permitted action_blocked — the specific use-case (training/search/ai_input) is blocked bot_blocked — the named agent is explicitly listed as blocked stance_blocks_all — the domain blocks all AI access site-wide no_policy — no policy is on file; treat as block per spec guidance unspecified — the action or use-case is not addressed by the policy lookup_error — the registry could not be reached

Args: domain: The domain to check (e.g. "nytimes.com"). action: One of: train, scrape, summarize, search, index, cache, inference, ai_input. agent_id: Optional self-reported agent name (e.g. "GPTBot", "ClaudeBot"). If provided and listed in the domain's blocked-bots list, the decision is bot_blocked.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`domain`	Yes
`agent_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It fully discloses the return structure (allowed bool, reason code, explanation, domain stance, signals), enumerates all reason codes and their meanings, explains the bot_blocked condition, and clarifies that no_policy/unspecified result in block behavior. This is exemplary transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but well-structured with a lead sentence, a return summary, a reason-code list, and an Args section. Each section earns its place; the reason-code enumeration is somewhat lengthy but valuable for interpreting results. It is appropriately sized for the tool's complexity.

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?

The tool has three parameters, an output schema, and requires nuanced policy handling. The description covers the input format, allowed actions, return values, and all possible decision outcomes, including error cases. There is no significant missing context that an agent would need to invoke this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema has no descriptions (0% schema coverage), the description thoroughly explains all three parameters: domain with an example, action with an explicit enum-like list, and agent_id with its optionality and behavioral effect (bot_blocked). It adds far more meaning than the bare schema, compensating completely.

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 a specific verb ('Check whether') and names the exact resource ('a specific action on a given domain'), and it clearly differentiates itself from sibling lookup tools by focusing on AI-agent permission decisions. It even enumerates the exact actions covered (scrape, summarize, train, search), making the purpose unmistakable.

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 explicit guidance: 'Use this before your agent scrapes, summarizes, trains, or searches content from a site.' It clearly states when to invoke the tool, though it doesn't explicitly name alternatives for cases where a plain domain lookup would suffice. Still, the intended usage context is well defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_changelogA

Get AI policy change history from the Maango registry.

Returns recent policy changes across domains. Filter by domain and/or change type.

Args: domain: Optional domain to filter by (e.g. "nytimes.com"). Leave empty for all. change_type: Optional filter. One of: stance_changed, bots_changed, score_changed, signals_added, signals_removed, use_case_changed, new_policy, multiple_changes. Leave empty for all. limit: Results per page (1-200, default 50). offset: Pagination offset (default 0).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`domain`	No
`offset`	No
`change_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool returns recent policy changes and supports pagination via limit/offset, but it does not mention ordering, time range, or explicitly state that it is a read-only operation. These details are left to the user's inference.

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 compact and well-structured: a clear opening sentence, a brief summary sentence, and a focused parameter list. Every part earns its place, and the front-loaded verb phrase immediately establishes the tool's purpose.

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?

With four optional parameters and an output schema present, the description covers the key aspects of filtering and pagination. It does not explicitly discuss when to use this tool versus siblings, but the name and description make that reasonably clear. Minor omission of output-related context is acceptable given the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since the input schema has 0% description coverage, the description fully compensates with an Args section that explains every parameter: domain with an example, change_type with a complete list of allowed values, limit with a valid range and default, and offset with its purpose. This adds significant meaning beyond the raw schema.

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 'Get AI policy change history from the Maango registry,' which is a specific verb+resource. It clearly distinguishes this tool from siblings like lookup_domain and search_domains by focusing on change history across domains.

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 explains what the tool does and how to filter by domain and change type, but it does not explicitly mention when to use this tool over alternatives or provide any exclusions. Usage context is implied but not directly contrasted with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_domainA

Look up a domain's AI policy summary from the Maango registry.

Returns the domain's overall AI stance (blocks_all_ai, selective, allows_all, no_policy), per-use-case policies (training, search, inference), blocked/allowed bot lists, signal presence (robots.txt, ai.txt, llms.txt), and site metadata.

Args: domain: The domain to look up (e.g. "nytimes.com").

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the tool's output behavior comprehensively by enumerating returned content (AI stance, per-use-case policies, bot lists, signal presence, site metadata). However, it omits details on error handling, authentication, or rate limits.

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 concise and well-structured: one sentence for purpose, a bullet-like list of return items, and a parameter specification. Every sentence adds value with no 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?

For a single-parameter lookup with an output schema, the description is fairly complete: it explains the purpose, parameter, and return content in detail. While it lacks usage context relative to siblings, that gap is already reflected in the usage_guidelines score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides a dedicated 'Args' section defining 'domain' with a format example ('nytimes.com'). This fully compensates for the lack of schema descriptions, giving clear semantic meaning to the single parameter.

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: 'Look up a domain's AI policy summary from the Maango registry.' The verb 'look up' and resource 'domain's AI policy summary' are specific, and the use of 'summary' implicitly distinguishes it from the sibling tool 'lookup_domain_full'.

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 usage for retrieving a summary for a single domain, but provides no explicit guidance on when to use this tool versus siblings like lookup_domain_full, search_domains, or check_permission. No alternative tools or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_domain_conflictsA

Get policy conflicts for a domain from the Maango registry.

Returns any conflicting signals between a domain's different policy files (e.g. robots.txt says one thing, ai.txt says another).

Args: domain: The domain to check for conflicts (e.g. "nytimes.com").

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses the output behavior ('Returns any conflicting signals') and gives an illustrative example. However, it does not explicitly state read-only safety, permissions, or other operational characteristics, though 'Get' implies a safe read.

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 compact and front-loaded with the purpose. It includes a brief explanatory sentence and a straightforward args list, with no wasted words or unnecessary detail.

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 simple one-parameter lookup tool, the description covers purpose, output meaning, and parameter example. It lacks explicit usage guidelines, but that gap is already captured elsewhere. Overall, it is complete enough for correct invocation.

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 single parameter 'domain' is explained with a concrete format and example ('e.g. "nytimes.com"'), adding semantic meaning that the input schema lacks (0% coverage). This adequately compensates for the schema's bare string type.

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 verb ('Get') and resource ('policy conflicts for a domain from the Maango registry'), and it differentiates from siblings like lookup_domain and lookup_domain_full by focusing specifically on conflicting policy signals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternative lookup tools. The description implies conflict checking but does not explicitly state selection criteria or mention alternative approaches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_domain_fullA

Get full raw policy data for a domain from the Maango registry.

Returns all parsed policy fields including raw robots.txt rules, ai.txt content, llms.txt sections, TDM-Rep data, crawl rules, meta tags, and content signals. Much more detailed than lookup_domain.

Args: domain: The domain to look up (e.g. "nytimes.com").

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description takes on the burden of disclosing behavior. It enumerates the returned data fields (robots.txt, ai.txt, llms.txt, TDM-Rep, crawl rules, meta tags, content signals), giving the agent a solid mental model. It doesn't mention side effects or failure modes, but as a read-only lookup, the disclosure 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?

The description is compact and well-structured. The first sentence states the purpose, the second lists return categories, and an 'Args' section handles the parameter. Every sentence earns its place with no redundancy or wordy filler.

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 the tool's purpose, output contents, and the lone parameter. An output schema exists, which handles return-value structure details, so the description doesn't need to over-explain. It lacks edge-case information, but for a detailed lookup tool with rich output schema, it is sufficiently complete.

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 input schema has only a 'domain' property with no description. The tool description compensates by defining it as 'The domain to look up' with an example ('nytimes.com'). This adds meaning beyond the schema, though it doesn't specify constraints like whether subdomains are accepted or if a protocol is needed, leaving slight ambiguity.

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 starts with a clear verb and resource: 'Get full raw policy data for a domain from the Maango registry.' It distinguishes itself from the sibling lookup_domain by explicitly stating it is 'much more detailed', leaving no ambiguity about its specific scope.

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 when to use this tool by emphasizing its comprehensive detail and contrasting it with lookup_domain. However, it doesn't explicitly state 'use this when you need full data' as a directive or list exclusions, so it falls just short of fully explicit usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_domainsA

Search for domains in the Maango AI policy registry by prefix.

Returns matching domains with their stance and Tranco rank.

Args: query: Domain prefix to search for (e.g. "news", "google"). Min 2 chars. stance: Optional filter. One of: blocks_all_ai, selective, allows_all, no_policy, blocks_training. Leave empty for no filter. limit: Results per page (1-100, default 20). offset: Pagination offset (default 0).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`offset`	No
`stance`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It discloses meaningful behavioral details: prefix matching, a 2-character minimum, accepted stance values, limit range 1-100, default 20, and offset pagination. It does not mention case sensitivity or result ordering, but the provided details are sufficient for safe use.

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 compact and well-structured: a one-sentence purpose, a one-sentence return summary, and a terse Args block. Every sentence adds useful information, and there is no redundant or filler content.

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 four parameters, an output schema, and no annotations, the description covers all necessary invocation knowledge: purpose, return content, parameter meanings, constraints, and defaults. The output schema handles return structure, so no further explanation of return values is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description's Args section adds thorough semantics for every parameter: query is a prefix with example and min length, stance has explicit allowed values, limit has a range and default, and offset has a default. This exceeds what the bare input schema provides.

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: 'Search for domains in the Maango AI policy registry by prefix.' It also states what is returned ('matching domains with their stance and Tranco rank'), which clearly distinguishes prefix search from exact-match sibling tools like lookup_domain.

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 use case is implied by 'by prefix' and the parameter details, but there is no explicit when-to-use or when-not-to-use guidance, nor any named alternative such as lookup_domain for exact matches. The agent must infer that prefix search is intended for partial/unknown domain names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation4/5

Tools are largely distinct with clear purposes, but the three lookup_domain variants (summary, full, conflicts) could be confused if descriptions are not read carefully. batch_check and check_permission are clearly separate from the lookup family.

Naming Consistency4/5

Most tools follow a verb_noun snake_case pattern (lookup_domain, get_changelog, check_permission, search_domains). batch_check deviates slightly as noun_verb, but the naming remains readable and predictable overall.

Tool Count5/5

Seven tools is well within the ideal range for a registry query service. Each tool fulfills a distinct query need with no unnecessary overlap or bloat.

Completeness5/5

The server covers the full spectrum of registry queries: single-domain summary, full raw data, conflicts, permission checking, batch comparison, domain search, and change history. There are no obvious gaps for a read-only policy registry.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

agent-ready-kit A
com.mudko
Agent-readiness scanner (0-5 score), robots.txt + llms.txt generators, managed agent enablement.
Agent Orchestration Browser Automation Developer Tools
262
VITNA — Agent Compliance Preflight A
xyz.costrinity
Pre-action allow/deny for AI agents. 24 statutes, 13 jurisdictions: EU AI Act, GDPR, DPDP.
Legal & Compliance Security Autonomous Agents
231
governance-platform A
ai.geodesiclabs
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
AI & Machine Learning Testing & QA Tools Monitoring
373
agentgauge A
io.github.GlassCaseOfEmotion
Scan any website's AI readiness: AI search visibility and AI agent usability. Free, no auth.
Browser Automation Search Agent Orchestration
12

Related MCP Servers

unphurl-mcp
Web Scraping Security Search
123Ergo
A
license
A
quality
D
maintenance
URL intelligence for AI agents. One URL in, structured security and data quality signals out across 7 dimensions. 13 tools, risk score 0-100 with 23 configurable weights.
Updated 4 months ago (2026-04-23 14:24 UTC)
16
110
1
MIT
blackwall-mcp
Security Autonomous Agents Monitoring
bluetieroperations-create
A
license
A
quality
D
maintenance
A pre-action risk gate for AI agents. Your agent calls the forecast tool before any irreversible action — send email, run SQL, make a payment, delete a file — and gets a risk score (0–100) and a GO / CONFIRM / STOP verdict in a few seconds.
Updated 6 days ago (2026-08-28 16:31 UTC)
1
519
MIT
maxaeo-ai-visibility-mcp
Web Scraping Search
maxaeo
A
license
A
quality
A
maintenance
Enables AI agents to check whether a public website is crawlable, understandable, and ready for AI search workflows through local-only audits of robots.txt, sitemaps, metadata, and llms.txt.
Updated 9 days ago (2026-08-26 07:56 UTC)
3
51
1
MIT
MCP Permission Guard
AMEOBIUS-space
A
license
Not graded
quality
C
maintenance
A pre-action authorization server for AI agents that classifies tool calls into 14 intent categories, scores risk 0-100, and produces deterministic allow/deny/ask decisions with full audit trail.
Updated a month ago (2026-07-21 17:22 UTC)
MIT

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/maango-io/maango-mcp'

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

Maango MCP Server

Why

Tools exposed

Reason codes returned by check_permission

Installation

Claude Desktop (remote, recommended)

Cursor

Cline / Zed / any MCP client

Local development (stdio)

Self-hosting

How it works

Observability

Development

Roadmap (not in v0.1)

Contributing

Links

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Reason codes returned by `check_permission`