request_dataFREE, no payment. Describe in your own words the data you are trying to buy — anything, not just packages — and get back whether we operate a service that supplies it, with the MCP endpoint if so. Every request is catalogued so repeatedly-requested data gets built. Nothing identifying is stored, only the words of the request.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What you are looking for. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / need / examplesAdded value: +[
+ "live electricity spot prices by ZIP"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It adds meaningful behavior beyond the name and schema: the request is free, every request is catalogued for future building, and no identifying information is stored. This is significant transparency for a tool that accepts free-form input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the most important fact (FREE, no payment). Every sentence contributes distinct information: scope, response behavior, cataloguing, and privacy. There is no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description covers the core interaction well: what to provide, what response to expect, and privacy/storage implications. It does not specify fallback behavior when no service exists, but that is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the 'need' parameter. The description adds context that the input should be a natural-language data request and can cover 'anything, not just packages', but it doesn't add syntax, formatting, or example details beyond the schema's own example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action: describe desired data and get back whether a matching service exists, with the MCP endpoint if so. It also explicitly contrasts with the package-focused siblings by saying 'anything, not just packages', making the tool's scope clear and distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for general data requests beyond the package-focused sibling tools, but it never explicitly tells the agent when to choose this tool over package_info, package_audit, or others. There is no 'use X instead when...' guidance, only an implicit contrast with 'not just packages'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
package_audit overlaps with package_info and package_vulnerabilities because it bundles their data, but the descriptions clearly frame audit as the combined decision-oriented call and the others as individual fact or advisory lookups. demand_report and request_data are also distinct: one is aggregate market demand, the other is a single request submission.
Three tools share the package_ prefix with descriptive suffixes (audit, info, vulnerabilities), while demand_report and request_data cover the demand-side features without the prefix. All names are snake_case and readable, so the deviation is minor rather than chaotic.
Five tools is a well-scoped size for a package intelligence server. Each tool maps to a meaningful workflow: package facts, vulnerabilities, a composite audit, individual data requests, and an aggregate demand report.
The package workflow is covered end-to-end: check package info, check advisories, and get a combined audit verdict before adding or pinning a dependency. The demand side also feels complete with both individual request_data and the aggregated demand_report.