Skip to main content
Glama
u9401066

pubmed-search-mcp

by u9401066
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

test_institutional_access

Read-onlyIdempotent

Check whether a configured institutional link resolver is reachable and returns a valid response, helping diagnose access setup issues.

Instructions

Test your institutional link resolver configuration.

═══════════════════════════════════════════════════════════════════════════════ 🧪 TEST INSTITUTIONAL ACCESS ═══════════════════════════════════════════════════════════════════════════════

Tests if your configured link resolver is:

  1. Properly configured

  2. Reachable (network connection)

  3. Returns a valid response

NOTE: This only tests if the resolver endpoint is reachable. Actual full-text access depends on your institution's subscriptions.

═══════════════════════════════════════════════════════════════════════════════ FREE TEST OPTIONS: ═══════════════════════════════════════════════════════════════════════════════

If you don't have institutional access, you can test with:

  1. Use "test_free" preset (EBSCO public resolver): configure_institutional_access(preset="test_free") test_institutional_access()

  2. Most university resolvers will respond even without VPN, they just won't provide full-text (shows "Access options" page)

Args: pmid: PMID to use for testing (default: 38353755)

Returns: Test results including: - Configuration status - Network reachability - Generated OpenURL - Link to test manually

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pmidNo38353755

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.7.2
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / pmid / maxLength
      Added value: +32
    • addedInput schema / properties / pmid / minLength
      Added value: +1
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "test_institutional_accessOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.5.16

TDQS

A3.9/5.0
Behavior4/5

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

Annotations cover readOnly/idempotent/openWorld, but the description adds meaningful behavioral context: it clarifies that the test only verifies endpoint reachability, not full-text access, which is a critical limitation not expressed in annotations. Also documents the default pmid and expected return fields.

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

Conciseness2/5

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

Heavily over-styled with ASCII dividers and duplicated headers (title repeats the name, banner box, repeated 'FREE TEST OPTIONS'). The core signal is buried under decorative formatting, wasting many tokens for a one-parameter tool.

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?

Covers purpose, limitation note, test options, argument default, and return shape. For a simple read-only test tool this is largely sufficient, with minor room to be tighter.

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 description coverage is 0% and the single pmid parameter has no description in the schema; the description explains pmid is the PMID to use for testing with a default (38353755), adding needed meaning. Baseline for 1 param with low coverage is 3, and the added detail matches that.

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?

States a specific verb (test) and resource (institutional link resolver configuration), and enumerates exactly what is being checked: configured, reachable, valid response. Clearly distinguishable from siblings like configure_institutional_access and diagnose_institutional_access.

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?

Provides clear when-to-use context via the FREE TEST OPTIONS section explaining how to test without institutional access, and notes what the test does and does not verify. Slightly fewer explicit exclusions vs alternatives, but functional.

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

Deploy Server

Other Tools