Skip to main content
Glama
edithatogo

OSF CLI Go

by edithatogo
OverviewSchemaRelated ServersScoreDiscussions
Go
Local

osf-cli-go

A Go command-line client for the Open Science Framework (OSF).

CI Lint Security Go Reference License Go Version Release OSF CLI Go MCP server

Features

  • osf auth whoami — Identify the authenticated OSF account

  • osf auth login — Guided personal-access-token bootstrap for username/password users

  • osf projects list|get — List and inspect projects

  • osf components list — List project components

  • osf files list|download|upload|mkdir|rm — Browse, download, upload, create folders, and delete OSF Storage files

  • osf search, osf search --bibtex, osf preprints list|search, and osf resolve — Search/export OSF literature metadata, discover preprints, and resolve OSF DOI destinations

  • osf registrations create — Create draft registrations for an existing node

  • osf export — Export a node snapshot as JSON or a summary table

  • osf validate — Check OSF node metadata with deterministic research-output or preregistration profiles

  • osf-mcp — Stdio MCP server exposing read-only OSF tools for agent clients

  • osf completion bash|zsh|fish|powershell — Shell completion scripts

  • JSON and human-readable output modes

  • Safe, atomic file downloads with conflict policy (fail/skip/overwrite)

Related MCP server: trocco-mcp-tools

Install

Requirements:

  • Go 1.26 or newer

go install github.com/edithatogo/osf-cli-go/cmd/osf@latest
go install github.com/edithatogo/osf-cli-go/cmd/osf-mcp@latest

Or from a local checkout:

go build -o bin\osf.exe ./cmd/osf
go build -o bin\osf-mcp.exe ./cmd/osf-mcp
.\scripts\build.ps1

Authentication

Set OSF_TOKEN in your shell session. Do not commit the token or write it into project files. OSF_USERNAME and OSF_PASSWORD are supported as an opt-in fallback credential source, but personal access tokens remain preferred for automation and for accounts using SSO or two-factor authentication.

$env:OSF_TOKEN = '<your-token>'

For guided token setup:

osf auth login

Quick Start

osf --help
osf auth whoami
osf projects list
osf projects get https://osf.io/abc12/
osf components list abc12
osf files list abc12
osf files download --file <file-id> ./output/
osf files download --tree abc12 ./output/
osf files upload --node abc12 ./report.pdf
osf search "open science"
osf search "open science" --bibtex
osf preprints list
osf preprints search "open science" --provider osf
osf resolve 10.1234/example
osf registrations create abc12 --schema <schema-id> --title "Analysis plan"
osf export abc12 --json

MCP Server

osf-mcp runs a stdio MCP server with read-only tools: osf_whoami, osf_projects_list, osf_project_get, osf_components_list, osf_files_list, osf_contributors_list, osf_search, osf_preprints_list, osf_preprints_search, and osf_doi_resolve.

The parity discovery tools are bounded and deterministic: osf_search requires a non-empty query and accepts a limit from 1 to 100, while osf_preprints_list accepts an optional provider and the same bounded limit. osf_preprints_search requires a title query, accepts an optional provider, and returns publication date, published state, DOI, and OSF HTML URL with a limit from 1 to 100. These tools return structured JSON through the MCP server and never perform writes.

OSF search results include stable IDs, title, abstract, keywords, year, and URL. Use osf search <query> --bibtex to emit deterministic BibTeX records for literature-review workflows. The command does not resolve contributor names or download PDFs automatically.

For DataLad workflows, OSF CLI Go provides the general-purpose OSF API and safe file primitives used around a dataset, including osf export and osf files download --tree. It does not install or configure DataLad, Git remotes, or git-annex special remotes; those integrations remain a separately scoped interoperability boundary.

Local development configs are included for GitHub Copilot, VS Code, Claude, Codex, Gemini CLI, and Qwen Code. Public registry metadata is in server.json and registry/.

Related MCP Servers

Other maintained servers in the same Glama portfolio:

Related OSF ecosystem servers:

Output Modes

All commands support --output table|json and --json shorthand:

osf projects list --json
osf auth whoami --output json

Project Status

The CLI is offline-tested for read-only operations, file downloads, WaterButler write primitives, search, preprint listing, draft registration creation, project create/update/delete operations, and node export. All Conductor tracks are reconciled against their per-track plans with closeout review evidence; live OSF validation remains opt-in because it requires credentials and network access.

Documentation

License

Apache 2.0 — see LICENSE.

Citation

If you use this software in your research, please cite it using the metadata in CITATION.cff.

Available Tools

6 tools
osf_components_listA

List immediate child components for an OSF project or component.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesOSF project/component id or URL

Output Schema

ParametersJSON Schema
NameRequiredDescription
nodesYes

TDQS

A3.5/5.0
Behavior3/5

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

The description mentions 'immediate' children, indicating it does not list nested components recursively. However, it does not disclose authentication needs, pagination, error handling, or behavior on invalid IDs. No annotations are provided, so the description carries full burden.

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, succinct sentence that efficiently conveys the core function. It is front-loaded and to the point.

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 simple list operation with one parameter and an existing output schema, the description is adequate. It does not elaborate on return format or pagination, but the context of this low-complexity tool does not demand more detail.

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 100% with a clear parameter description. The tool description adds no extra meaning beyond stating the action, so baseline 3 is appropriate.

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 clearly states the tool lists immediate child components for an OSF project or component. It uses a specific verb and resource, and distinguishes from sibling tools like osf_contributors_list or osf_files_list by focusing on components.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like osf_projects_list or osf_project_get. No mention of prerequisites, conditions, or when not to use it.

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

osf_contributors_listC

List contributors for an OSF project or component.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesOSF project/component id or URL

Output Schema

ParametersJSON Schema
NameRequiredDescription
contributorsYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the basic function, omitting details like authentication requirements, pagination, handling of empty results, or constraints (e.g., requires valid project/component ID).

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. It is appropriately concise for its purpose, though it could benefit from slightly more detail without becoming verbose.

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

Completeness3/5

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

Given the presence of an output schema (not provided), the description could omit return value details. However, it lacks context about pagination, result format, or usage scope, making it minimally adequate for a straightforward listing tool.

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 100%: the parameter 'id' is already described as 'OSF project/component id or URL'. The description adds no further meaning beyond what the schema provides, meeting the baseline of 3.

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 description clearly states the verb 'List' and the resource 'contributors' for an OSF project or component. It is specific and unambiguous, but does not explicitly distinguish from siblings like 'osf_components_list' or 'osf_project_get', which could be inferred by the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or situations where another tool (e.g., 'osf_project_get') would be more appropriate.

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

osf_files_listB

List OSF Storage files and folders for a project/component, optionally below a path.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesOSF project/component id or URL
pathNooptional path below OSF Storage

Output Schema

ParametersJSON Schema
NameRequiredDescription
filesYes

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. However, it only states the basic listing operation without detailing any traits like recursive listing, pagination, authorization needs, or whether the operation is read-only. Minimal transparency.

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

Conciseness5/5

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

The description is a single, succinct sentence of 14 words that conveys the essential function without any wasted verbiage. Front-loaded with the key action and resource.

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?

Given the presence of an output schema, return values are likely covered elsewhere. However, the description omits behavioral context (e.g., traversal mode, permissions, rate limits) and usage guidance, making it insufficient for an agent to fully understand the tool's behavior and when to invoke it.

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?

The input schema already describes both parameters (id and path) with 100% coverage. The description adds no new meaning beyond restating the schema, so baseline 3 applies.

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 clearly states the action 'List' and the resource 'OSF Storage files and folders' for a project/component, and specifies optional path filtering. It effectively distinguishes from sibling tools like 'osf_components_list' or 'osf_contributors_list' which deal with different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of when not to use it, such as for uploading or modifying files, nor any context about prerequisites or limitations.

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

osf_project_getB

Get an OSF project or component by id or URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesOSF project/component id or URL

Output Schema

ParametersJSON Schema
NameRequiredDescription
nodeYes

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, and the description lacks any behavioral details such as authentication requirements, error handling, or side effects. With no annotations, the burden falls entirely on the description, which is insufficient.

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

Conciseness5/5

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

Single sentence, no repetition, front-loaded with purpose. Extremely concise.

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?

With an output schema present, the description need not explain return values. The description is complete for a simple get operation, though it could mention the type of output for clarity.

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 100%, and the description adds minimal extra meaning beyond the schema. The schema already describes the id parameter as 'OSF project/component id or URL', matching the description.

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 clearly states the action (Get), resource (OSF project or component), and method (by id or URL). It distinguishes from sibling list tools like osf_projects_list and osf_components_list which handle collections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as osf_components_list or osf_projects_list. No mention of prerequisites or context for use.

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

osf_projects_listA

List projects owned by the authenticated OSF user.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
nodesYes

TDQS

A3.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it lists owned projects, but does not mention whether pagination is supported, rate limits, or that it only returns projects where the user is the owner (not contributor). More detail would be helpful.

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

Conciseness5/5

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

The description is a single sentence that is perfectly concise and front-loaded. Every word is necessary and there is no waste.

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

Completeness5/5

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

Given the simplicity of the tool (no parameters, no nested objects) and the presence of an output schema, the description is complete enough to inform the agent about what the tool does. It does not need to explain return values since the output schema handles that.

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

Parameters4/5

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

The input schema has zero parameters, so the description does not need to add parameter meaning. According to the guidelines, 0 parameters leads to a baseline score of 4. The description provides no extra parameter info, which is acceptable here.

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 clearly states the tool lists projects owned by the authenticated OSF user. The verb 'List' and the resource 'projects owned by the authenticated OSF user' are specific. This distinguishes it from siblings like osf_components_list (lists components) and osf_project_get (gets a single project).

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?

The description implies usage when you need to list the authenticated user's projects, but it does not explicitly state when to avoid using this tool or provide alternatives. For example, if you need a specific project's details, osf_project_get would be more appropriate, but this is not mentioned.

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

osf_whoamiA

Return the authenticated OSF user profile.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
userYes

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It clearly states a read operation ('Return'), implying no side effects. This is sufficient for a simple read tool, though it does not mention authentication requirements or error conditions.

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

Conciseness5/5

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

The description is a single sentence that immediately conveys the tool's purpose. No extraneous information, front-loaded, and efficient.

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

Completeness5/5

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

Given zero parameters, an output schema is present (handling return values), and the tool performs a straightforward read operation, the one-line description is complete and requires no additional context.

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

Parameters4/5

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

There are no parameters, and schema coverage is 100% (empty schema). The description inherently adds no parameter info, but none is needed. Baseline score of 4 applies as there is nothing to improve.

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 'Return the authenticated OSF user profile' uses a specific verb ('Return') and resource ('user profile'), clearly distinguishing it from sibling tools that operate on components, contributors, files, or projects.

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?

The description implies usage for retrieving the current user's profile but provides no explicit guidance on when to use versus alternatives or any exclusions. Sibling tools cover different resources, making the purpose inferrable but not stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updatesv0.1.0
    • First observedosf_components_list
    • First observedosf_contributors_list
    • First observedosf_files_list
    • First observedosf_project_get
    • First observedosf_projects_list
    • First observedosf_whoami
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool targets a distinct resource (components, contributors, files, project, projects list, user profile) with no overlapping purposes, making it easy for an agent to select the correct tool.

Naming Consistency4/5

All tools share the 'osf_' prefix and use snake_case, generally following a 'noun_list' or 'noun_get' pattern. The exception is 'osf_whoami', which deviates slightly, but overall consistency is high.

Tool Count5/5

With 6 tools, the server is well-scoped for basic OSF query operations. The count is appropriate for the focused read-only functionality offered.

Completeness3/5

The tool set covers read operations (list, get) for core OSF entities but lacks write, update, or delete actions, leaving obvious gaps for a full lifecycle. Agents can query but not modify data.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/edithatogo/osf-cli-go'

If you have feedback or need assistance with the MCP directory API, please join our Discord server