EdgeStore

Agents

Use EdgeStore documentation, CLI, and hosted MCP with coding agents.

Coding agents can use EdgeStore's Markdown documentation to integrate file uploads and its hosted MCP or CLI to work with remote resources.

Use documentation for your package version

Check the EdgeStore versions installed in the application workspace before making changes. A globally installed CLI may be newer than the application's packages.

The v1 prerelease documentation is available at next.edgestore.dev. Applications still using 0.2 should use the stable documentation until explicitly choosing to migrate. Do not mix examples from these versions or upgrade an existing application without approval.

  • llms.txt lists documentation pages.
  • llms-full.txt provides the documentation in one Markdown response.
  • Add .md to a documentation URL, such as Quick Start Markdown, to read that page as Markdown.
  • Every documentation page has a Copy Markdown button.

Start with the adapter for your application: Next.js, Hono, or TanStack Start. Reuse the application's existing backend, environment-file convention, and storage provider.

Connect the hosted MCP

Add https://api.edgestore.dev/mcp as a remote HTTP MCP server in your agent's MCP settings. Use the client's OAuth flow when you need access to your account. Available tools depend on the permissions granted to the connection.

Prefer MCP for supported remote actions when it is connected. Use the EdgeStore CLI for local project linking, protected credential delivery, or actions unavailable through MCP. Do not repeat a resource-creation operation through both tools.

The hosted endpoint above is production. Do not assume the docs preview uses a separate test account or API. Select the intended account and project before changing resources, and use an explicitly configured non-production environment for automated live tests.

Credentials and implementation choices

Keep project secrets in the backend's loaded, gitignored environment file. Do not paste secrets into prompts, commit them, or put them in frontend variables such as VITE_*.

Choose a bucket name that fits the application and make the public or protected access policy clear before implementing. Ask when access requirements are ambiguous or sensitive. Reuse existing resources where appropriate, and confirm destructive operations before running them.

Verify the application

Run relevant application typechecks and builds, then test an upload through the application's own client and server route. Independently retrieve the uploaded file to verify the result. API health or a CLI-only upload does not exercise the full application integration.

Use edgestore doctor for existing CLI configuration and connectivity checks. If authentication, browser access, or a running application is unavailable, explain what passed locally and what still needs verification. Keep secrets and signed URLs out of the final report, and clean up only test resources you are authorized to remove.

On this page