library-enrichment

Overview Schema Source Related Servers Discussions Admin

Resolve Library

resolve_library

Idempotent

Pin down the exact release and environment for a Rust or Python library before searching docs, source, or release evidence.

Instructions

Establish exact identity and environment before research.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	Research mode. Defaults to `project` with a version and `upstream` without.
`name`	Yes	Crate or distribution name.
`extras`	No
`target`	No	Your project's target triple or platform, if known.
`version`	No	Exact version. Omit only for an explicit upstream question.
`features`	No	Rust features your project enables; use extras for Python.
`revision`	No
`ecosystem`	Yes	Which package ecosystem.
`freshness`	No	`cache_ok` retains exact-version evidence indefinitely; latest selection has a TTL. `revalidate` always consults the registry; `offline` never opens a socket.	cache_ok
`repository`	No
`allow_yanked`	No
`package_subdir`	No
`python_version`	No
`allow_prerelease`	No
`default_features`	No	Whether your project enables default features, if known.
`allow_local_build`	No	Accept a local rustdoc build when docs.rs JSON is missing or in an unreadable format, or its observed build differs from requested features/target. Compiles the crate on a dated nightly in an isolated capsule and can take minutes. Requires the operator-enabled `build` profile; asking never grants it.

Output Schema

TableJSON Schema

Name	Required	Description
`job`	Yes
`data`	Yes
`error`	Yes
`status`	Yes
`summary`	Yes
`coverage`	Yes
`delivery`	Yes	Delivery changes representation, never the original research status or coverage.
`evidence`	Yes
`artifacts`	Yes
`freshness`	Yes
`context_id`	Yes
`request_id`	Yes
`snapshot_id`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.0.0Sep 16, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations declare idempotentHint=true and destructiveHint=false, so there is no contradiction here. However, the description adds no behavioral context beyond the outcome: it does not disclose network usage, caching, writes, build-time cost, or failure modes, which matters given readOnlyHint=false and openWorldHint=true.

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?

The description is a single front-loaded sentence with no filler and is easy to parse. It may be too spare, but its brevity is still a strength.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter tool without readOnlyHint and with many research-oriented siblings, a one-sentence description is inadequate. It does not explain what 'environment' includes, when this tool should be called relative to others, or what inputs drive the resolution, despite an output schema existing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 56%, and the description provides no parameter-level guidance. Several parameters such as revision, repository, allow_yanked, package_subdir, and python_version are not described in the schema or the description, so the description does not compensate for the gaps.

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?

The phrase 'Establish exact identity and environment before research' names a concrete outcome (resolved package identity/environment) and frames it as a pre-research step. It is not a tautology and conveys a clear job for the agent, though it does not explicitly differentiate it from siblings like library_overview or search_evidence.

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?

'Before research' implies this tool should be used first, but the description never states when to choose it over library_overview, search_evidence, or compare_releases, nor any exclusions. Usage context is only implied, not explicitly specified.

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

Deploy Server