fip-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| communitiesC | Known communities and the FIP each one has published. Any tool below also accepts a FIP nanopub URI in place of a short name. |
| profileA | The community's FAIR choices, question by question, from the LATEST version
of its FIP (the supersedes chain is followed and returned as
|
| recommendA | What the community has agreed for one topic, with each resource's URL and description. Call this BEFORE suggesting a repository, file format, licence, vocabulary or identifier scheme to a researcher in this community. topic: identifier, metadata-schema, linking, repository, protocol, access, longevity, format, vocabulary, references, licence, provenance, standards — or a FAIR principle such as "I1". |
| checkA | Check a folder or a Zenodo record against the community's FIP. target: a local folder path, a Zenodo record URL or id, or a Zenodo DOI. The verdicts are deterministic: each declared resource is matched to a probe
of facts read from the target (DOIs, licence, repository, file formats,
RO-Crate). Statuses: pass, fail (with |
| crosswalkC | What changes when a workflow or dataset moves from the |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a distinct role: listing communities, retrieving a community profile, giving a topic recommendation, checking a target, and comparing two communities. The boundaries between profile, recommend, check, and crosswalk are clear from their descriptions, and the shared FIP URI input convention does not create selection ambiguity.
All tool names are single lowercase words, which is a readable and consistent surface style. However, they mix nouns and verbs (communities/profile vs recommend/check), so they do not follow a strict action-oriented verb_noun pattern.
Five tools is well scoped for an FIP advisory/checking server: discovery, profile inspection, topic recommendation, compliance checking, and cross-community comparison. Each tool has a clear place, with no obvious redundancy or missing scale.
The surface covers the core read-only FIP workflows: finding communities, reading their latest profile choices, recommending agreed resources, checking targets, and crosswalking between communities. Minor gaps include no explicit topic/question listing tool and no broader FIP-authoring lifecycle, but these are not required for the apparent advisory purpose.