Skip to main content
Glama
derekslinz

meta-data-mcp

by derekslinz

Draft Spec

opendata_plugins_draft
Read-onlyIdempotent

Build a validated YAML plugin spec from structured inputs, ensuring correct id format, tool names, and parameter consistency before creating the plugin.

Instructions

Build a validated YAML plugin spec from structured inputs. Use this BEFORE opendata_plugins_create to avoid hand-writing YAML. Validates id format, kebab-case tool names, path-placeholder/param consistency, parameter types, and response format. Returns the YAML string ready to feed into opendata_plugins_create.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesPlugin id in snake_case, e.g. 'global_nvd_cve'. Becomes the Python module name under meta_data_mcp/providers/.
titleYesHuman-readable title for the registry entry.
toolsYesAt least one tool definition. Each becomes one MCP tool on the server.
domainsNoRegistry domains (e.g. ['security', 'government']).
regionsNoRegistry regions (e.g. ['global', 'us']).
base_urlYesAPI base URL with no trailing slash (e.g. 'https://services.nvd.nist.gov').
homepageYesURL to the API documentation or provider homepage.
keywordsNoSearch keywords that should match this plugin in opendata_providers_find.
descriptionYesOne- or two-sentence description of what this plugin covers.
server_nameNokebab-case server name for the plugin registry entry. Defaults to id with underscores replaced by hyphens.
requires_envNoNames of environment variables this API needs (e.g. ['NVD_API_KEY']).
Behavior4/5

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

Annotations already indicate readOnlyHint and idempotentHint. Description adds value by listing validations performed (id format, kebab-case, consistency checks) and output format, which are beyond the annotation scope.

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, front-loaded with main purpose, then usage guidance, validation details, and output. Every sentence serves a purpose with no redundancy.

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 tool's complexity (11 parameters, no output schema), the description adequately covers purpose, usage, validations, and output. It is sufficient for an agent to use correctly.

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 detailed descriptions for all 11 parameters. Tool description does not add extra parameter information, but baseline is 3 when schema is complete.

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?

Description clearly states 'Build a validated YAML plugin spec from structured inputs' with specific verb and resource. It also distinguishes from sibling 'opendata_plugins_create' by stating usage order.

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?

Explicitly says 'Use this BEFORE opendata_plugins_create to avoid hand-writing YAML', providing clear context and alternative. Does not explicitly state when not to use, but the guidance is sufficient.

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

Install Server

Other Tools

Latest Blog Posts

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/derekslinz/meta-data-mcp'

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