mister-parc-mcp

Sites en ligne

parc_sites

Read-onlyIdempotent

Check a fleet's GitHub Pages sites for reachability, HTTP status, response time, title, production freshness against main, and broken or transient URLs; filter to only failing or outdated sites.

Instructions

Les sites GitHub Pages du parc : répondent-ils (code HTTP, temps de réponse, titre), la production est-elle à jour face à main, et sert-elle des morceaux fugaces ou des URL mortes.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "parc_sites"
  }
}

Input Schema

Name	Required	Description	Default
`en_panne`	No	Ne garder que les sites injoignables ou en retard sur main.

Output Schema

Name	Required	Description	Default
`sites`	Yes
`genere`	Yes	Date du relevé qui fonde la réponse (ISO 8601).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 31, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds real value beyond that: it discloses that live HTTP requests are made and that latency, status codes, page titles, staleness versus `main` and dead links are compared – explaining the cost and the nature of the checks.

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?

A single front-loaded sentence introducing the resource before enumerating checks; no filler. It is dense and the trailing clause is slightly obscure, keeping it short of a 5.

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?

An output schema exists and annotations cover the safety profile, so the description need only describe scope. It does that well by enumerating the audited dimensions; only the filtering behavior of `en_panne` is left unmentioned.

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?

Only one parameter with 100% schema description coverage, so the schema fully documents `en_panne`. The description does not mention the filter at all, leaving the schema to carry it – baseline 3 is appropriate.

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?

States a specific resource (les sites GitHub Pages du parc) and the specific checks performed: HTTP code, response time, title, production vs `main`, transient assets and dead URLs. This clearly separates it from sibling repo-level tools like parc_depots and parc_depot, though the phrasing is dense and the 'morceaux fugaces' bit is ambiguous.

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?

Usage is only implied: an agent infers this is the tool for auditing deployed Pages sites. There is no explicit statement of when to pick it over parc_etat / parc_alertes, and no preconditions mentioned.

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