Server data from the Official MCP Registry
Agent integration with the Northwestern University Libraries Digital Collections API
Agent integration with the Northwestern University Libraries Digital Collections API
Remote endpoints: streamable-http: https://api.dc.library.northwestern.edu/api/v2/mcp
Valid MCP server (2 strong, 0 medium validity signals). 2 known CVEs in dependencies Package registry verified. Imported from the Official MCP Registry. Trust signals: 3 highly-trusted packages.
14 files analyzed · 3 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
Available as Local & Remote
This plugin can run on your machine or connect to a hosted endpoint. during install.
From the project's GitHub README.
env.jsonThe env.json file contains environment variable values for the lambda functions defined in the API for use in local development. You can create an env.json file containing the values to run the API against your dev data by running:
make env.json
If the file already exists, it will not be overwritten unless you include -B in the make command.
To start the API in development mode, first make sure you have the correct version of the AWS SAM command line utility installed:
asdf install aws-sam-cli
Then run the following command:
make serve
The API will be available at:
https://USER_PREFIX.dev.rdc.library.northwestern.edu:3002
⚠️ Note the above URLs (which point to your local OpenSearch instance) need full endpoints to resolve. For example:
https://USER_PREFIX.dev.rdc.library.northwestern.edu:3002/searchhttps://USER_PREFIX.dev.rdc.library.northwestern.edu:3002/collectionsView supported endpoints Questions? View the production API documentation
View and edit information about a specific Work in the Index.
id of a Work you'd like to inspect in the API.https://USER_PREFIX.dev.rdc.library.northwestern.edu:3002/works/[WORK_ID]https://USER_PREFIX.dev.rdc.library.northwestern.edu:3002/works/[WORK_ID]?as=iiifFor help debugging/inspecting, JavaScript console messages are written to: dc-api-v2/dc-api.log
Develop against changes to the API.
dc-nextjs/server.js from default 3000 to something like 3003.sgport open all 3003
/environment/dc-nextjs shell)export NEXT_PUBLIC_DCAPI_ENDPOINT=https://USER_PREFIX.dev.rdc.library.northwestern.edu:3002
npm run dev
Access the app in a browser at: https://USER_PREFIX.dev.rdc.library.northwestern.edu:3003/
# From the repo root
cd dc-api-v2
# Start the API + step function and associated lambdas
make start-with-step
# Open a second terminal and create the state machine
make state-machine
There are two ways to deploy a development branch: make deploy and make sync. The differences are:
deploy deploys a static stack, and requires another deploy to update it. sync watches for
changes in realtime.deploy uses the apiDependencies resource defined in the template for dependencies, while
sync uses the AWS SAM CLI's built-in development dependency logic.Either way, the resulting stack will be accessible at https://dcapi-USER_PREFIX.rdc-staging.library.northwestern.edu.
An existing sync stack can be reused by running make sync again, or by running make sync-code to only
sync code changes (no infrastructure/template changes).
samconfig.*.yamlBoth methods involve a samconfig.USER_PREFIX.yaml file. This file, with default values, can be created by
running (for example):
make samconfig.mbk.yaml
This will create a configuration to stand up the default stacks in both deploy mode (API, AV Download, and Chat) and
sync mode (Chat only). To deploy a different combination of features, specify them using the WITH option:
make samconfig.mbk.yaml WITH=API,DOCS
Available features are: API, AV_DOWNLOAD, CHAT, and DOCS.
⚠️ Be very careful including the API in sync mode as every change within /api will take a long time to deploy.
As with the env.json file, make will not overwrite an existing file unless you include -B.
sam delete --stack-name dc-api-USER_PREFIX
API documentation is automatically regenerated and deployed on pushes to the staging and production branches. The documentation is in two parts:
The docs directory contains a standard mkdocs project, which can be edited using the same tools and format as the main Repository Documentation.
In a nutshell:
docs/docs directory.mkdocs locally and preview your work:
sgport open all 8000
make serve-docs
Docs will be accessible at http://USER_PREFIX.dev.rdc.library.northwestern.edu:8000/We also maintain an OpenAPI Specification under the docs directory in spec/openapi.yaml. When mkdocs is running, the Swagger UI can be found at http://USER_PREFIX.dev.rdc.library.northwestern.edu:8000/spec/openapi.html. Like the rest of the documentation, changes to the YAML will be immediately visible in the browser.
The existing spec files (openapi.yaml, types.yaml, and data-types.yaml) are the best reference for understanding and updating the spec. It's especially important to understand how openapi.yaml uses the $ref keyword to refer to reusable elements defined in types.yaml, and how types.yaml pulls model schemas from data-types.yaml.
For an in-depth look, or to learn how to define things for which there aren't good examples in our spec, refer to the full OpenAPI documentation.
openapi.html renders the Swagger UI directly from the unmodified openapi.yaml. In addition, the build process generates a JSON copy of the spec using the OpenAPI Generator CLI. In order to make sure the spec is valid before checking it in, run:
npm run validate-spec
This check is also part of the CI test workflow, so an invalid spec file will cause the branch to fail CI.
Typescript types for the schemas (Works, Collections, FileSets) are automatically published to the nulib/dcapi-types repo on deploys.
deploy/staging branch contains changes to the docs/docs/spec/data-types.yaml file, new types are generated and a commit is made to the staging branch of nulib/dcapi. This is intended to be for local testing by NUL devs against the private staging API.main branch) contains changes to the docs/docs/spec/data-types.yaml file, new types are generated and a PR is opened into the main branch of nulib/dcapi-types. Also, an issue is created in nulib/repodev_planning_and_docs to review the PR and publish the types package (manually).The current API version is maintained in several different project files. To increment the version, use
make version BUMP=<major|minor|patch>
If you don't specify a BUMP value, the command will simply print the current version.
Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
by mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.