WritersLogic verifiable AI agents

symbol-exists

Is this export in the npm package's published type declarations — Checks that up to 20 named exports (functions, classes, constants, types, default) exist in the .d.ts files published for an exact npm package version, read from jsDelivr, for coding agents that may be calling an API that does not exist. Follows export lists and relative export-star re-exports within the package (at most 7 files) and reports when the export surface cannot be fully enumerated. Neve

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "package": "<package>",
      "version": "<version>",
      "symbols": "<symbols>"
    },
    "name": "symbol-exists"
  }
}

Input Schema

Name	Required	Description
`entry`	No	package.json exports key, default '.'.
`package`	Yes	npm package name.
`symbols`	Yes
`version`	Yes	Exact version or dist-tag (jsDelivr resolves it).
`typesPath`	No	Declaration file path inside the package, overriding package.json resolution.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the data source (jsDelivr), the traversal rules (follows export lists and relative export-star re-exports, at most 7 files), and the explicit failure mode of reporting when the export surface cannot be fully enumerated. It does not say what happens when the package or version itself is unresolvable, which is the main remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the content is dense with useful constraints, but it is delivered as one long run-on sentence with an em-dash aside, and the text is visibly truncated mid-word ('Neve'), which is a structural defect an agent must work around.

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?

For a five-parameter, no-output-schema, no-annotation tool, the description covers source, scope, traversal limits, and non-enumerable-surface reporting well. It leaves gaps only around behavior when the package/version/file cannot be resolved and around the shape of the answer, which the name partially implies.

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 80%, so the baseline is 3. The description reinforces the symbols parameter (up to 20, including types and default) but says nothing about entry or typesPath, both of which override package.json resolution and are only explained by the schema.

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 opens with a precise question ('Is this export in the npm package's published type declarations') and then names the verb, resource, and scope: up to 20 named exports checked against .d.ts files for an exact version. An agent can tell this apart from the package-exists sibling because the scope is explicitly 'export surface' rather than package presence.

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?

It supplies a usage context — 'for coding agents that may be calling an API that does not exist' — which tells the agent when the tool is relevant. However, it names no alternative tool (such as package-exists) and gives no when-not-to-use conditions, and the truncated trailing sentence ('Neve') likely removed further caveats.

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

All WritersLogic verifiable AI agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?