How do I use boutique-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@boutique-mcp search for EU law connectors" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

boutique-mcp

by matematicsolutions

Overview Schema Related Servers Score Discussions

Python

Local

boutique-mcp

A local MCP catalog of MateMatic Boutique: 103 entries at the time of writing - 43 legal-data MCP connectors (SAOS, CBOSA, EUR-Lex, national ELI servers from Austria to Japan), 52 MateMatic agent skills and 8 curated third-party skills.

It answers one question: which building block solves the task at hand, and how to install it locally. The catalog points, it never proxies. Your agent gets a copy-paste uvx/npx command or a download link and runs it on your machine.

Status: v0.1.0 | License: Apache-2.0 | Maintainer: MateMatic

Why local

A hosted discovery API sees every query it answers, and in legal work the query itself is often confidential ("counter-arguments to our client's position in..."). This connector never sees anything: search runs in-process over a local copy of catalog.json. The only network request it ever makes is a conditional GET of the public catalog itself (ETag / If-None-Match).

No network? You get the last catalog cached on disk, or the snapshot shipped inside the package. Either way the response says where the data came from and how old it is: "catalog generated on X, source: network / disk-cache / bundled-snapshot". Nothing is installed or executed for you. The catalog returns commands; you run them.

Related MCP server: mcp-server-mcpindex

MCP tools

boutique_search(query, jurisdiction?, entry_type?, limit?) - keyword search (English, Polish or Portuguese) over the catalog. Every hit carries a local install command. When coverage is missing, the response says so in gaps[] instead of padding weak matches.
boutique_get(id) - the full card for one entry: names and descriptions in every available language, install, version, license, source and card URLs.
boutique_whats_new(since_date?) - what was added or updated since a date (default: the 30 days before the catalog was generated).
boutique_coverage() - declares what this catalogue covers, where it comes from and what it does NOT cover. Every gap carries a stable id and a fallback. Call it when a search returns nothing: the absence may be a gap in the catalogue.
boutique_request_coverage(description, jurisdiction?) - drafts a coverage-request issue for a gap. Draft only: nothing is sent anywhere; a human reviews and submits it.

Quickstart

uvx boutique-mcp

MCP client configuration (mcp-servers.json):

{
  "mcpServers": {
    "boutique": {
      "command": "uvx",
      "args": ["boutique-mcp"]
    }
  }
}

Windows 11 with Smart App Control

Smart App Control blocks unsigned executables, which covers uvx.exe, pip.exe and the boutique-mcp.exe launcher that pip writes at install time. The python.exe and py.exe from the python.org installer are signed by the Python Software Foundation, so running the module through the interpreter works:

python -m pip install boutique-mcp
python -m boutique_mcp

pip.exe is blocked for the same reason, so install with python -m pip, not pip install. If python is not on PATH, use the Windows launcher: py -3 -m boutique_mcp.

{ "mcpServers": { "boutique-mcp": { "command": "python", "args": ["-m", "boutique_mcp"] } } }

Do not turn Smart App Control off to work around this - it cannot be re-enabled without reinstalling Windows.

Configuration

Env	Default	Meaning
`BOUTIQUE_MCP_CATALOG_URL`	`https://matematicsolutions.com/catalog.json`	Catalog source
`BOUTIQUE_MCP_CACHE_DIR`	`~/.matematic/cache/boutique-mcp`	Disk cache location
`BOUTIQUE_MCP_OFFLINE`	unset	`1` = never touch the network
`BOUTIQUE_MCP_AUDIT`	unset	`1` = opt-in local audit log (tool name + timing only, never query content)

Data source

catalog.json is generated in the www-matematic repository from the same source as the Boutique page tiles (three languages); a pre-commit and CI check fails whenever the two drift apart. A machine-readable server card lives at /.well-known/mcp/server-card.json.

Development

python -m venv .venv
.venv/bin/pip install -e ".[dev]"        # Windows: .venv\Scripts\pip
.venv/bin/python -m pytest tests/ -q     # offline - fixture catalog
.venv/bin/python -m ruff check src tests

Governance

The project constitution forbids a hosted discover/invoke proxy and any logging of query content. The only adoption metric MateMatic sees is the CDN download counter of the public catalog.json file. The one tool that produces outbound text, boutique_request_coverage, stops at a draft; a human submits it.

Constitution and spec: .matematic/ in this repository.

Available Tools

4 tools

boutique_getA

Read-onlyIdempotent

Full catalog card for one entry: names, descriptions and card URLs in every available language, install command, version, license, source URL.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	the entry id from boutique_search (e.g. "mcp-saos", "de-eli-mcp", "humanizer-pl").

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

The annotations already declare the operation as safe (readOnly, idempotent, non-destructive). The description adds value by detailing what the returned catalog card contains (e.g., 'names, descriptions and card URLs in every available language'), which is not covered by annotations. It does not disclose error behavior or rate limits, but the output schema covers return structure.

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, front-loaded sentence that immediately states the scope ('Full catalog card for one entry') and then enumerates the included fields. Every word earns its place; there is no redundancy or 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?

This is a simple single-parameter read operation with rich annotations and an output schema. The description clearly explains what the tool returns and is fully complete for an agent to select and invoke it correctly, especially given the sibling tools and parameter context.

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 'id' has 100% schema description coverage, including examples from boutique_search. The tool description does not add additional parameter semantics beyond what the schema already provides, so 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 starts with 'Full catalog card for one entry,' which clearly identifies a retrieval operation for a single catalog item. It lists the specific content fields (names, descriptions, card URLs, install command, version, license, source URL), making the tool's purpose concrete. This also distinguishes it from sibling boutique_search, which searches across entries.

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 phrase 'for one entry' clearly indicates this tool is for fetching a specific catalog item, implying the user should already have an entry id. The schema further specifies id comes from boutique_search, but the description itself does not explicitly mention alternatives or exclusions. Still, the context is clear enough for an agent to know when to use it.

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

boutique_request_coverageA

Read-onlyIdempotent

Draft a coverage-request issue for a gap in the Boutique catalog.

DRAFT ONLY - this tool performs no network call and submits nothing. A human reviews the draft and submits it at the returned URL.

ParametersJSON Schema

Name	Required	Description	Default
`description`	Yes	what is missing and for what task (plain language).
`jurisdiction`	No	optional jurisdiction the gap concerns.

Output Schema

ParametersJSON Schema

Name	Required	Description
`body`	Yes
`title`	Yes
`disclaimer`	Yes
`submit_url`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

The description goes beyond the annotations by explicitly stating 'DRAFT ONLY', 'performs no network call', and 'submits nothing'. It also explains the human-review workflow and that submission happens via a returned URL. This is critical behavioral context that aligns with and enriches the readOnlyHint and idempotentHint annotations.

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 front-loaded with the main purpose. The separate line 'DRAFT ONLY - this tool performs no network call and submits nothing.' is a clear, high-impact warning. The additional sentence about human review and the returned URL provides necessary workflow context without unnecessary 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?

For a tool with 2 parameters (1 required) and no nested objects, the description fully covers the tool's behavior, limitations, and follow-up action. Since an output schema exists, there's no need to describe return values. The description is complete for an agent to correctly invoke the tool and interpret its result, even with siblings present.

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 already provides full descriptions for both parameters ('what is missing...' and 'optional jurisdiction...'), so the schema coverage is 100%. The description itself does not add further parameter details, but it doesn't need to; the baseline 3 applies because the schema carries the heavy lifting and the description doesn't contradict or omit anything.

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 drafts a coverage-request issue for a gap in the Boutique catalog, using a specific verb ('draft') and resource ('coverage-request issue'). It also distinguishes itself from the read-only sibling tools by explicitly noting it performs no network call and only creates a draft for human submission.

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 there is a gap in the catalog and clarifies the draft-only workflow, which tells the agent when to use this tool (for requesting new coverage) and what to expect (no actual submission). It doesn't explicitly name alternatives, but the sibling tools are all read-only, so this tool stands out as the only one for creating a request.

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

boutique_searchA

Read-onlyIdempotent

Search the MateMatic Boutique catalog for connectors and skills.

ParametersJSON Schema

Name	Required	Description
`limit`	No	max hits (1-25, default 10).
`query`	Yes	keywords in English, Polish or Portuguese (e.g. "case law Poland", "anonimizacja", "German law").
`entry_type`	No	optional filter: "konektor" (MCP connector), "skill" (MateMatic skill) or "kuratorski" (curated third-party skill).
`jurisdiction`	No	optional filter, matched against the entry's jurisdiction label (e.g. "Polska", "EU", "Brasil").

Output Schema

ParametersJSON Schema

Name	Required	Description
`gaps`	No
`hits`	No
`query`	Yes
`provenance`	Yes	Where the catalog data in this response came from, and how old it is.

TDQS

A3.6/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no new behavioral context beyond restating the search scope. It does not describe return format, pagination, or any operational characteristics, but given the strong annotations, this is acceptable.

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, concise sentence: 'Search the MateMatic Boutique catalog for connectors and skills.' It front-loads the core purpose with no unnecessary words, making it easy to parse and appropriately sized for a straightforward search tool.

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?

Given the comprehensive schema with parameter descriptions, the presence of an output schema, and clear annotations, the description is sufficient for an agent to understand the tool's role. It doesn't explain return values (covered by output schema) or filters (covered by schema), and it adequately states the search scope. A slightly more detailed mention of multi-language support or filtering options could improve it, but it is not essential.

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?

All four parameters have detailed descriptions in the schema (query, limit, entry_type, jurisdiction), achieving 100% schema_description_coverage. The description adds no additional parameter semantics, so the baseline of 3 applies as the schema already carries the full burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search the MateMatic Boutique catalog for connectors and skills' clearly identifies the action (search) and the resource (MateMatic Boutique catalog), with scope limited to connectors and skills. It implicitly differentiates from sibling tools like boutique_get and boutique_whats_new through the verb 'search', though it does not explicitly name alternatives.

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?

No explicit when-to-use or when-not-to-use guidance is provided. The tool's name and description imply a search use case, but there are no mentions of alternatives or exclusions. The context of sibling tools suggests this is for finding items, but the description alone does not clarify when to prefer this over boutique_get or boutique_request_coverage.

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

boutique_whats_newA

Read-onlyIdempotent

What was added to or updated in the Boutique catalog since a date.

ParametersJSON Schema

Name	Required	Description	Default
`since_date`	No	ISO date (YYYY-MM-DD). Default: 30 days before the catalog's generated_at date (deterministic offline - no system clock involved).

Output Schema

ParametersJSON Schema

Name	Required	Description
`added`	No
`since`	Yes
`updated`	No
`provenance`	Yes	Where the catalog data in this response came from, and how old it is.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the temporal delta semantics but no additional behavioral caveats such as pagination or output size 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?

A single sentence that is front-loaded and contains no redundant words. It effectively communicates the core purpose without unnecessary elaboration.

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?

Given the low complexity (one optional parameter), strong annotations, and presence of an output schema, the description is mostly sufficient. It could be improved by explicitly contrasting with sibling tools, but the essential information for invocation is present.

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 coverage is 100% with a detailed description for since_date, including ISO format, default, and deterministic offline behavior. The tool description adds no new parameter information, so 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 states exactly what the tool does: lists additions and updates to the Boutique catalog since a specified date. The temporal scoping distinguishes it from siblings like boutique_search and boutique_get, which focus on search and retrieval rather than change history.

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?

The description provides no explicit guidance on when to use this tool versus alternatives. It implies use for catalog changes since a date, but never mentions sibling tools or when another tool would be more appropriate.

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.1/5.0

Disambiguation5/5

Each tool targets a distinct operation: searching, retrieving full details, checking updates, and requesting coverage. No overlap in purpose or expected usage.

Naming Consistency4/5

All tools share the 'boutique_' prefix and use clear action-oriented names, though 'whats_new' is a noun phrase rather than a verb_noun style like the others. The consistency is strong but not perfect.

Tool Count5/5

With 4 tools, the server is tightly scoped to the catalog domain. Each tool serves a necessary function without redundancy or bloat.

Completeness5/5

The toolset covers discovery (search, get, whats_new) and contribution (request_coverage), forming a complete lifecycle for interacting with the boutique catalog. No obvious gaps such as missing listing or submission capabilities.

Maintenance

ActivityMaintained

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

Lulu Registry MCP A
io.github.Lulu-The-Narwhal
Search and get install details on MCP servers, right from your agent -- a unified marketplace index.
Developer Tools Search Documentation Access
21
MCP Marketplace A
io.mcp-marketplace
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
Developer Tools Search
72
MCP Registry Search A
io.github.Spacemandomains
Search and browse every MCP server in the Model Context Protocol registry.
Search Developer Tools
321
H-Index A
ai.xr-utilities
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Search Documentation Access
32

Related MCP Servers

skill4agent MCP Server
Autonomous Agents Developer Tools Search
osulivan
A
license
B
quality
D
maintenance
MCP (Model Context Protocol) Server for skill4agent - Search, view, and install AI skills in AI conversations.
Updated 6 months ago (2026-02-20 08:19 UTC)
3
24
4
MIT
mcp-server-mcpindexofficial
Developer Tools Search Security
mcpindex-ai
A
license
A
quality
B
maintenance
Enables agents to discover, compare, and install other MCP servers using natural language tasks, backed by a searchable index of thousands of servers.
Updated 15 days ago (2026-08-18 04:43 UTC)
6
227
MIT
agentalmanac-mcp
Search Developer Tools Agent Orchestration
survivorforge
A
license
A
quality
D
maintenance
Enables searching and retrieving details of 9,000+ MCP servers from the Agent Almanac catalog, allowing agents to discover, inspect, and install tools directly.
Updated 3 months ago (2026-05-20 14:23 UTC)
3
46
MIT
MCPfinderofficial
Agent Orchestration Developer Tools
mcpfinder
A
license
Not graded
quality
A
maintenance
AI-first MCP server discovery tool that enables agents to search, inspect, and install MCP servers from multiple registries.
Updated 5 days ago (2026-08-27 17:03 UTC)
12
AGPL 3.0

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/matematicsolutions/boutique-mcp'

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

boutique-mcp

Why local

MCP tools

Quickstart

Windows 11 with Smart App Control

Configuration

Data source

Development

Governance

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

skill4agent MCP Server

mcp-server-mcpindexofficial

agentalmanac-mcp

MCPfinderofficial

Latest Blog Posts

MCP directory API