entryscape 1.3.0__py3-none-any.whl

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (82) hide show
  1. entryscape/__init__.py +219 -0
  2. entryscape/api/__init__.py +26 -0
  3. entryscape/api/app_token_api.py +835 -0
  4. entryscape/api/auth_api.py +965 -0
  5. entryscape/api/catalog_api.py +4473 -0
  6. entryscape/api/contact_api.py +3135 -0
  7. entryscape/api/dataservice_api.py +3135 -0
  8. entryscape/api/dataset_api.py +3804 -0
  9. entryscape/api/distribution_api.py +3135 -0
  10. entryscape/api/document_api.py +2740 -0
  11. entryscape/api/idea_api.py +2740 -0
  12. entryscape/api/job_api.py +360 -0
  13. entryscape/api/model_api.py +2446 -0
  14. entryscape/api/model_class_api.py +2611 -0
  15. entryscape/api/model_diagram_api.py +2611 -0
  16. entryscape/api/model_field_api.py +2611 -0
  17. entryscape/api/model_form_api.py +2611 -0
  18. entryscape/api/model_namespace_api.py +2611 -0
  19. entryscape/api/model_property_api.py +2611 -0
  20. entryscape/api/organization_api.py +3135 -0
  21. entryscape/api/search_api.py +1513 -0
  22. entryscape/api/showcase_api.py +2740 -0
  23. entryscape/api/suggestion_api.py +2740 -0
  24. entryscape/api/terminology_api.py +1726 -0
  25. entryscape/api/upload_api.py +814 -0
  26. entryscape/api_client.py +763 -0
  27. entryscape/api_response.py +20 -0
  28. entryscape/configuration.py +673 -0
  29. entryscape/exceptions.py +222 -0
  30. entryscape/models/__init__.py +71 -0
  31. entryscape/models/app_token.py +156 -0
  32. entryscape/models/app_token_create_request.py +98 -0
  33. entryscape/models/app_token_create_response.py +169 -0
  34. entryscape/models/app_token_status.py +35 -0
  35. entryscape/models/app_token_verify_request.py +109 -0
  36. entryscape/models/entity_list_item.py +175 -0
  37. entryscape/models/entity_list_response.py +139 -0
  38. entryscape/models/entity_reference.py +189 -0
  39. entryscape/models/entity_type.py +57 -0
  40. entryscape/models/error.py +135 -0
  41. entryscape/models/facet_field.py +115 -0
  42. entryscape/models/facet_field_values_inner.py +100 -0
  43. entryscape/models/facet_list.py +113 -0
  44. entryscape/models/facet_list_available_inner.py +107 -0
  45. entryscape/models/job_response.py +112 -0
  46. entryscape/models/job_status.py +189 -0
  47. entryscape/models/job_status_progress.py +100 -0
  48. entryscape/models/job_status_value.py +37 -0
  49. entryscape/models/job_type.py +37 -0
  50. entryscape/models/list_catalogs_entry_type_parameter.py +37 -0
  51. entryscape/models/list_catalogs_graph_type_parameter.py +44 -0
  52. entryscape/models/list_catalogs_resource_type_parameter.py +37 -0
  53. entryscape/models/login_request.py +108 -0
  54. entryscape/models/login_response.py +115 -0
  55. entryscape/models/metadata_format.py +38 -0
  56. entryscape/models/metadata_request.py +99 -0
  57. entryscape/models/parent_reference.py +130 -0
  58. entryscape/models/search_request.py +158 -0
  59. entryscape/models/search_request_filters.py +144 -0
  60. entryscape/models/search_request_filters_graph_type.py +44 -0
  61. entryscape/models/search_request_filters_resource_type.py +37 -0
  62. entryscape/models/search_request_sort.py +38 -0
  63. entryscape/models/search_request_sort_order.py +35 -0
  64. entryscape/models/search_response.py +175 -0
  65. entryscape/models/search_result.py +175 -0
  66. entryscape/models/search_result_graph_type.py +44 -0
  67. entryscape/models/search_result_resource_type.py +37 -0
  68. entryscape/models/search_sort_order_parameter.py +35 -0
  69. entryscape/models/terminology_import_mode.py +35 -0
  70. entryscape/models/validation_profile.py +36 -0
  71. entryscape/models/validation_response.py +149 -0
  72. entryscape/models/validation_result.py +162 -0
  73. entryscape/models/validation_severity.py +36 -0
  74. entryscape/models/validation_summary.py +122 -0
  75. entryscape/models/whoami_response.py +104 -0
  76. entryscape/py.typed +0 -0
  77. entryscape/rest.py +210 -0
  78. entryscape-1.3.0.dist-info/METADATA +696 -0
  79. entryscape-1.3.0.dist-info/RECORD +82 -0
  80. entryscape-1.3.0.dist-info/WHEEL +5 -0
  81. entryscape-1.3.0.dist-info/licenses/LICENSE.txt +165 -0
  82. entryscape-1.3.0.dist-info/top_level.txt +1 -0
@@ -0,0 +1,189 @@
1
+ # coding: utf-8
2
+
3
+ """
4
+ EntryScape API
5
+
6
+ This API provides structured access to EntryScape data following DCAT-AP standards. All entity endpoints follow a consistent pattern: - GET /{entity} - List all entities - POST /{entity} - Create a new entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id} - Get entity reference info - DELETE /{entity}/{context_id}/{entry_id} - Delete an entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id}/metadata - Get raw RDF metadata - PUT /{entity}/{context_id}/{entry_id}/metadata - Replace raw RDF metadata (JSON-LD, Turtle, RDF/XML, or N-Triples passthrough) ## Reading and consistency Reads of a single entity — `GET /{entity}/{context_id}/{entry_id}` and its `/metadata` — go straight to the store and always reflect the latest write. Lists and search do not. They are answered from a search index that is updated asynchronously, so for a short interval after a write: - an entry that was just created may be missing from the list it belongs to, while reading it by id already works; - an entry that was just deleted may still appear; - `results` counts what the index holds, not what the store holds. Write a client that tolerates this: after creating an entry, use the id the create returned rather than searching for what you just wrote. `results` is also an upper bound rather than an exact count when the caller cannot read every hit (see the field's own description). Separately, responses are cached for 15 minutes by default, which is a second and unrelated source of staleness. A write invalidates the cache entries it affects, but a read that lands in the indexing gap can cache a list that does not yet show it. ## Authentication Most endpoints require an authenticated session. Reading public data works without authentication, while creating, updating, and deleting entities requires a valid user session. 1. **Log in** with `POST /auth/login`, supplying an EntryStore username and password. The response returns an `auth_token`. 2. **Send the token** on subsequent requests via the `X-Auth-Token` header. This is the recommended method for SDK and programmatic access. Browser clients can instead rely on the `auth_token` cookie, which the server sets automatically on login (`SameSite=Lax; Secure`). 3. **Inspect the session** with `GET /auth/whoami`, which returns the current user or an anonymous/guest identity when no valid token is supplied. 4. **Log out** with `POST /auth/logout` to invalidate the token and clear the cookie. ### Writes and CSRF Send the token as the `X-Auth-Token` **header** and there is nothing else to do: creates, updates and deletes work as they are, which is how the SDKs and the MCP server are built. The `auth_token` cookie is different. A cookie is attached by the browser automatically, so a state-changing request authenticated by it alone is what cross-site request forgery abuses, and those requests additionally need a double-submit token: read the `XSRF-TOKEN` cookie the server sets on any response and send its value back as the `X-XSRF-TOKEN` header. Without it the request is rejected with `403` before it reaches the endpoint. A custom header cannot be forged this way — cross-origin JavaScript cannot set one without a CORS preflight, which this API grants only to configured origins — so the header is the recommended path for anything that is not a browser session. ### App Tokens An app token identifies an integration. Create one with `POST /app-token` (unauthenticated). Creation requires an email address: the token starts in the `pending` state and a 6-digit code is emailed to the owner. Confirm the code with `POST /app-token/verify` to activate the token and receive its value, which is shown only once — store it securely. `GET /app-token/{app_token_id}` then returns its details and quota usage, authenticated by the token itself via the `X-App-Token` header. **The `X-App-Token` header is accepted only by `GET /app-token/{app_token_id}`.** No other operation reads it, and the read quota is recorded but not yet enforced: reading public data needs no token of any kind, and sending an app token with a read neither grants nor meters anything. Metered public read access is the intent of the two-token model, not a description of this release — see the `security` declared on each operation for what it actually accepts. ## SDKs Generated clients for Python, TypeScript, JavaScript and C# wrap every operation below, and each operation on this page shows the SDK call beside the `curl` command. Two of them install from a public registry: ``` pip install entryscape # Python npm install @entryscape/api-client # TypeScript and JavaScript ``` `@entryscape/api-client` ships an ESM and a CommonJS build, so `import` and `require()` both work and TypeScript is not required to use it — the name describes what it is written in, not what you have to write. There is a separate generated JavaScript SDK, and it is deliberately **not** on npm; this package is the npm client for both languages. Every SDK, including the C# and JavaScript ones, is also published as a tarball. The downloads are linked in the sidebar, they are the route to take when a registry is unreachable or a build has to vendor its dependencies, and each archive carries the SDK's own README: - **Python** — `pip install entryscape`, or `python-sdk.tar.gz`. - **TypeScript and JavaScript** — `npm install @entryscape/api-client`, or `typescript-sdk.tar.gz`. - **JavaScript (the separate generated client)** — not published to a registry, by design; `javascript-sdk.tar.gz` only. - **C#** — not published to NuGet yet; `csharp-sdk.tar.gz` only. - **MCP server** — `npx -y @entryscape/mcp-server`, or `mcp-server.tar.gz`. ## MCP Server A Model Context Protocol (MCP) server is generated from this specification and published alongside the SDKs (`@entryscape/mcp-server`), exposing the API as tools for AI assistants and agents. Each operation becomes one tool named after its `operationId` — `listDatasets`, `createCatalog`, `search`, `getJobStatus`. The `auth` operations are the exception: the server reads its token once at startup, so a `login` tool could install nothing and a `logout` tool would only invalidate the token the server was started with. On connect the server also hands the assistant a short set of rules that hold across every tool: a token is bound to one EntryStore instance, the search index lags a write, uploads finish as jobs. ### Install The server is on npm, and MCP servers are normally launched straight from there, so nothing has to be installed first: ``` npx -y @entryscape/mcp-server ``` `npm install -g @entryscape/mcp-server` works too and puts an `entryscape-mcp` binary on `PATH`. It is also listed in the MCP Registry as `com.entryscape/mcp-server`, which is where clients and marketplaces look it up. Without npm, download `mcp-server.tar.gz` from the SDK downloads and unpack it. The package ships prebuilt; install its runtime dependency once: ``` mkdir entryscape-mcp && tar -xzf mcp-server.tar.gz -C entryscape-mcp cd entryscape-mcp && npm install --omit=dev ``` ### Configure The server is a stdio MCP server configured through environment variables, read once at startup: - `ENTRYSCAPE_API_URL` — base URL of the API server, path included. Required: there is no default, and the server refuses to start without it. - `ENTRYSCAPE_AUTH_TOKEN` — a session token from `POST /auth/login`, sent as the `X-Auth-Token` header. Optional: without it reads see public entries and every write is refused. A token is valid only for the EntryStore instance that issued it. - `ENTRYSCAPE_ENTRYSTORE_HOST` — the EntryStore instance the API server should use, for example `dev.entryscape.com/store/`. Unset means the API server's own default. - `ENTRYSCAPE_MCP_UPLOAD_ROOT` — the directory the upload tools may read files from. **Unset means uploads are disabled**: `addFileToDistribution`, `replaceFileInDistribution` and `importTerminology` refuse and say so. - `ENTRYSCAPE_MCP_TAGS` — comma-separated tags to serve tools for, for example `catalog,dataset,distribution,search`. Unset serves every tool. The package's `README.md` lists the remaining variables (timeouts and size caps). Register the server with any MCP-capable client by adding it to the client's `mcpServers` configuration: ```json { \"mcpServers\": { \"entryscape\": { \"command\": \"npx\", \"args\": [\"-y\", \"@entryscape/mcp-server\"], \"env\": { \"ENTRYSCAPE_API_URL\": \"https://<your EntryScape API host>\", \"ENTRYSCAPE_AUTH_TOKEN\": \"your-session-token\" } } } } ``` From an unpacked download instead, the command is `\"command\": \"node\", \"args\": [\"/path/to/entryscape-mcp/dist/bin/entryscape-mcp.js\"]`. ### Claude Code The unpacked package is also a Claude Code plugin, so one install gives the server and the skills below together. Claude Code installs plugins from marketplaces, and the package carries a one-entry marketplace pointing at itself: ``` claude plugin marketplace add /path/to/entryscape-mcp claude plugin install entryscape@entryscape --scope user ``` The plugin passes `ENTRYSCAPE_API_URL`, `ENTRYSCAPE_AUTH_TOKEN`, `ENTRYSCAPE_ENTRYSTORE_HOST`, `ENTRYSCAPE_MCP_TAGS` and `ENTRYSCAPE_MCP_UPLOAD_ROOT` through from the shell Claude Code was started in, so set them there. To try the plugin for one session without installing it, start Claude Code with `--plugin-dir /path/to/entryscape-mcp`. ### Skills `skills/` in the package holds procedures that span several tools, in the Agent Skills format (a `SKILL.md` with `name` and `description`): which tools to call in which order, what to check between calls, and where to stop. Claude Code loads them from the plugin; other clients that read the format can be pointed at the directory. The `find` skill covers discovery, facets and selective metadata reads; `publish-dataset` takes a dataset from catalog to validated distribution with its file; `edit-metadata` changes an entry that already exists without dropping the rest of its graph, models included; `migrate-from-taskrunner` moves an integration off the deprecated Taskrunner API. Every tool a skill names is checked against this specification when the package is built. ## Deprecation Policy When endpoints or features are deprecated: 1. The operation is marked with `deprecated: true` in this spec 2. The operation description documents the replacement endpoint and sunset date 3. Deprecated endpoints remain functional for at least 6 months after announcement 4. The server returns a `Sunset` header with the planned removal date 5. After the sunset date, the endpoint may be removed in a future release
7
+
8
+ The version of the OpenAPI document: 1.3.0
9
+ Contact: contact@entryscape.com
10
+ Generated by OpenAPI Generator (https://openapi-generator.tech)
11
+
12
+ Do not edit the class manually.
13
+ """ # noqa: E501
14
+
15
+ from __future__ import annotations
16
+ import pprint
17
+ import re # noqa: F401
18
+ import json
19
+
20
+ from datetime import datetime
21
+ from pydantic import BaseModel, ConfigDict, Field, StrictInt, StrictStr
22
+ from typing import Any, ClassVar, Dict, List, Optional
23
+ from typing_extensions import Annotated
24
+ from entryscape.models.job_status_progress import JobStatusProgress
25
+ from entryscape.models.job_status_value import JobStatusValue
26
+ from entryscape.models.job_type import JobType
27
+ from typing import Optional, Set
28
+ from typing_extensions import Self
29
+ from pydantic_core import to_jsonable_python
30
+
31
+
32
+ class JobStatus(BaseModel):
33
+ """
34
+ Full status information for an asynchronous job.
35
+ """ # noqa: E501
36
+
37
+ job_id: StrictInt = Field(
38
+ description="Unique identifier for an upload job. Based on timestamp when the job was created. ",
39
+ alias="jobId",
40
+ )
41
+ status: JobStatusValue
42
+ job_type: JobType = Field(alias="jobType")
43
+ resource_uri: Optional[StrictStr] = Field(
44
+ default=None,
45
+ description="Target resource URI (distribution URI for file uploads)",
46
+ alias="resourceURI",
47
+ )
48
+ filename: Optional[
49
+ Annotated[str, Field(min_length=1, strict=True, max_length=512)]
50
+ ] = Field(
51
+ default=None,
52
+ description="Original filename (only present for file upload jobs)",
53
+ )
54
+ user: Annotated[str, Field(min_length=1, strict=True, max_length=256)] = Field(
55
+ description="Username who submitted the job"
56
+ )
57
+ queue_position: Optional[Annotated[int, Field(strict=True, ge=1)]] = Field(
58
+ default=None,
59
+ description="Position in queue (only present when status is PENDING)",
60
+ alias="queuePosition",
61
+ )
62
+ progress: Optional[JobStatusProgress] = None
63
+ result_url: Optional[StrictStr] = Field(
64
+ default=None,
65
+ description="URL to the created or updated resource (only present when status is SUCCESS). For an ADD job the resource URI of the new file entry, for a REPLACE job the file entry that was replaced, for an import the context that was created. ",
66
+ alias="resultUrl",
67
+ )
68
+ received: datetime = Field(description="Timestamp when the job was submitted")
69
+ terminated: Optional[datetime] = Field(
70
+ default=None,
71
+ description="Timestamp when the job completed (only present when status is SUCCESS or FAILED)",
72
+ )
73
+ error: Optional[Annotated[str, Field(strict=True, max_length=2000)]] = Field(
74
+ default=None, description="Error message (only present when status is FAILED)"
75
+ )
76
+ __properties: ClassVar[List[str]] = [
77
+ "jobId",
78
+ "status",
79
+ "jobType",
80
+ "resourceURI",
81
+ "filename",
82
+ "user",
83
+ "queuePosition",
84
+ "progress",
85
+ "resultUrl",
86
+ "received",
87
+ "terminated",
88
+ "error",
89
+ ]
90
+
91
+ model_config = ConfigDict(
92
+ validate_by_name=True,
93
+ validate_by_alias=True,
94
+ validate_assignment=True,
95
+ protected_namespaces=(),
96
+ )
97
+
98
+ def to_str(self) -> str:
99
+ """Returns the string representation of the model using alias"""
100
+ return pprint.pformat(self.model_dump(by_alias=True))
101
+
102
+ def to_json(self) -> str:
103
+ """Returns the JSON representation of the model using alias"""
104
+ return json.dumps(to_jsonable_python(self.to_dict()))
105
+
106
+ @classmethod
107
+ def from_json(cls, json_str: str) -> Optional[Self]:
108
+ """Create an instance of JobStatus from a JSON string"""
109
+ return cls.from_dict(json.loads(json_str))
110
+
111
+ def to_dict(self) -> Dict[str, Any]:
112
+ """Return the dictionary representation of the model using alias.
113
+
114
+ This has the following differences from calling pydantic's
115
+ `self.model_dump(by_alias=True)`:
116
+
117
+ * `None` is only added to the output dict for nullable fields that
118
+ were set at model initialization. Other fields with value `None`
119
+ are ignored.
120
+ * OpenAPI `readOnly` fields are excluded.
121
+ * OpenAPI `readOnly` fields are excluded.
122
+ * OpenAPI `readOnly` fields are excluded.
123
+ * OpenAPI `readOnly` fields are excluded.
124
+ * OpenAPI `readOnly` fields are excluded.
125
+ * OpenAPI `readOnly` fields are excluded.
126
+ * OpenAPI `readOnly` fields are excluded.
127
+ * OpenAPI `readOnly` fields are excluded.
128
+ """
129
+ excluded_fields: Set[str] = set(
130
+ [
131
+ "resource_uri",
132
+ "filename",
133
+ "user",
134
+ "queue_position",
135
+ "result_url",
136
+ "received",
137
+ "terminated",
138
+ "error",
139
+ ]
140
+ )
141
+
142
+ _dict = self.model_dump(
143
+ by_alias=True,
144
+ exclude=excluded_fields,
145
+ exclude_none=True,
146
+ )
147
+ # override the default output from pydantic by calling `to_dict()` of progress
148
+ if self.progress:
149
+ _dict["progress"] = self.progress.to_dict()
150
+ return _dict
151
+
152
+ @classmethod
153
+ def from_dict(cls, obj: Optional[Dict[str, Any]]) -> Optional[Self]:
154
+ """Create an instance of JobStatus from a dict"""
155
+ if obj is None:
156
+ return None
157
+
158
+ if not isinstance(obj, dict):
159
+ return cls.model_validate(obj)
160
+
161
+ # raise errors for additional fields in the input
162
+ for _key in obj.keys():
163
+ if _key not in cls.__properties:
164
+ raise ValueError(
165
+ "Error due to additional fields (not defined in JobStatus) in the input: "
166
+ + _key
167
+ )
168
+
169
+ _obj = cls.model_validate(
170
+ {
171
+ "jobId": obj.get("jobId"),
172
+ "status": obj.get("status"),
173
+ "jobType": obj.get("jobType"),
174
+ "resourceURI": obj.get("resourceURI"),
175
+ "filename": obj.get("filename"),
176
+ "user": obj.get("user"),
177
+ "queuePosition": obj.get("queuePosition"),
178
+ "progress": (
179
+ JobStatusProgress.from_dict(obj["progress"])
180
+ if obj.get("progress") is not None
181
+ else None
182
+ ),
183
+ "resultUrl": obj.get("resultUrl"),
184
+ "received": obj.get("received"),
185
+ "terminated": obj.get("terminated"),
186
+ "error": obj.get("error"),
187
+ }
188
+ )
189
+ return _obj
@@ -0,0 +1,100 @@
1
+ # coding: utf-8
2
+
3
+ """
4
+ EntryScape API
5
+
6
+ This API provides structured access to EntryScape data following DCAT-AP standards. All entity endpoints follow a consistent pattern: - GET /{entity} - List all entities - POST /{entity} - Create a new entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id} - Get entity reference info - DELETE /{entity}/{context_id}/{entry_id} - Delete an entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id}/metadata - Get raw RDF metadata - PUT /{entity}/{context_id}/{entry_id}/metadata - Replace raw RDF metadata (JSON-LD, Turtle, RDF/XML, or N-Triples passthrough) ## Reading and consistency Reads of a single entity — `GET /{entity}/{context_id}/{entry_id}` and its `/metadata` — go straight to the store and always reflect the latest write. Lists and search do not. They are answered from a search index that is updated asynchronously, so for a short interval after a write: - an entry that was just created may be missing from the list it belongs to, while reading it by id already works; - an entry that was just deleted may still appear; - `results` counts what the index holds, not what the store holds. Write a client that tolerates this: after creating an entry, use the id the create returned rather than searching for what you just wrote. `results` is also an upper bound rather than an exact count when the caller cannot read every hit (see the field's own description). Separately, responses are cached for 15 minutes by default, which is a second and unrelated source of staleness. A write invalidates the cache entries it affects, but a read that lands in the indexing gap can cache a list that does not yet show it. ## Authentication Most endpoints require an authenticated session. Reading public data works without authentication, while creating, updating, and deleting entities requires a valid user session. 1. **Log in** with `POST /auth/login`, supplying an EntryStore username and password. The response returns an `auth_token`. 2. **Send the token** on subsequent requests via the `X-Auth-Token` header. This is the recommended method for SDK and programmatic access. Browser clients can instead rely on the `auth_token` cookie, which the server sets automatically on login (`SameSite=Lax; Secure`). 3. **Inspect the session** with `GET /auth/whoami`, which returns the current user or an anonymous/guest identity when no valid token is supplied. 4. **Log out** with `POST /auth/logout` to invalidate the token and clear the cookie. ### Writes and CSRF Send the token as the `X-Auth-Token` **header** and there is nothing else to do: creates, updates and deletes work as they are, which is how the SDKs and the MCP server are built. The `auth_token` cookie is different. A cookie is attached by the browser automatically, so a state-changing request authenticated by it alone is what cross-site request forgery abuses, and those requests additionally need a double-submit token: read the `XSRF-TOKEN` cookie the server sets on any response and send its value back as the `X-XSRF-TOKEN` header. Without it the request is rejected with `403` before it reaches the endpoint. A custom header cannot be forged this way — cross-origin JavaScript cannot set one without a CORS preflight, which this API grants only to configured origins — so the header is the recommended path for anything that is not a browser session. ### App Tokens An app token identifies an integration. Create one with `POST /app-token` (unauthenticated). Creation requires an email address: the token starts in the `pending` state and a 6-digit code is emailed to the owner. Confirm the code with `POST /app-token/verify` to activate the token and receive its value, which is shown only once — store it securely. `GET /app-token/{app_token_id}` then returns its details and quota usage, authenticated by the token itself via the `X-App-Token` header. **The `X-App-Token` header is accepted only by `GET /app-token/{app_token_id}`.** No other operation reads it, and the read quota is recorded but not yet enforced: reading public data needs no token of any kind, and sending an app token with a read neither grants nor meters anything. Metered public read access is the intent of the two-token model, not a description of this release — see the `security` declared on each operation for what it actually accepts. ## SDKs Generated clients for Python, TypeScript, JavaScript and C# wrap every operation below, and each operation on this page shows the SDK call beside the `curl` command. Two of them install from a public registry: ``` pip install entryscape # Python npm install @entryscape/api-client # TypeScript and JavaScript ``` `@entryscape/api-client` ships an ESM and a CommonJS build, so `import` and `require()` both work and TypeScript is not required to use it — the name describes what it is written in, not what you have to write. There is a separate generated JavaScript SDK, and it is deliberately **not** on npm; this package is the npm client for both languages. Every SDK, including the C# and JavaScript ones, is also published as a tarball. The downloads are linked in the sidebar, they are the route to take when a registry is unreachable or a build has to vendor its dependencies, and each archive carries the SDK's own README: - **Python** — `pip install entryscape`, or `python-sdk.tar.gz`. - **TypeScript and JavaScript** — `npm install @entryscape/api-client`, or `typescript-sdk.tar.gz`. - **JavaScript (the separate generated client)** — not published to a registry, by design; `javascript-sdk.tar.gz` only. - **C#** — not published to NuGet yet; `csharp-sdk.tar.gz` only. - **MCP server** — `npx -y @entryscape/mcp-server`, or `mcp-server.tar.gz`. ## MCP Server A Model Context Protocol (MCP) server is generated from this specification and published alongside the SDKs (`@entryscape/mcp-server`), exposing the API as tools for AI assistants and agents. Each operation becomes one tool named after its `operationId` — `listDatasets`, `createCatalog`, `search`, `getJobStatus`. The `auth` operations are the exception: the server reads its token once at startup, so a `login` tool could install nothing and a `logout` tool would only invalidate the token the server was started with. On connect the server also hands the assistant a short set of rules that hold across every tool: a token is bound to one EntryStore instance, the search index lags a write, uploads finish as jobs. ### Install The server is on npm, and MCP servers are normally launched straight from there, so nothing has to be installed first: ``` npx -y @entryscape/mcp-server ``` `npm install -g @entryscape/mcp-server` works too and puts an `entryscape-mcp` binary on `PATH`. It is also listed in the MCP Registry as `com.entryscape/mcp-server`, which is where clients and marketplaces look it up. Without npm, download `mcp-server.tar.gz` from the SDK downloads and unpack it. The package ships prebuilt; install its runtime dependency once: ``` mkdir entryscape-mcp && tar -xzf mcp-server.tar.gz -C entryscape-mcp cd entryscape-mcp && npm install --omit=dev ``` ### Configure The server is a stdio MCP server configured through environment variables, read once at startup: - `ENTRYSCAPE_API_URL` — base URL of the API server, path included. Required: there is no default, and the server refuses to start without it. - `ENTRYSCAPE_AUTH_TOKEN` — a session token from `POST /auth/login`, sent as the `X-Auth-Token` header. Optional: without it reads see public entries and every write is refused. A token is valid only for the EntryStore instance that issued it. - `ENTRYSCAPE_ENTRYSTORE_HOST` — the EntryStore instance the API server should use, for example `dev.entryscape.com/store/`. Unset means the API server's own default. - `ENTRYSCAPE_MCP_UPLOAD_ROOT` — the directory the upload tools may read files from. **Unset means uploads are disabled**: `addFileToDistribution`, `replaceFileInDistribution` and `importTerminology` refuse and say so. - `ENTRYSCAPE_MCP_TAGS` — comma-separated tags to serve tools for, for example `catalog,dataset,distribution,search`. Unset serves every tool. The package's `README.md` lists the remaining variables (timeouts and size caps). Register the server with any MCP-capable client by adding it to the client's `mcpServers` configuration: ```json { \"mcpServers\": { \"entryscape\": { \"command\": \"npx\", \"args\": [\"-y\", \"@entryscape/mcp-server\"], \"env\": { \"ENTRYSCAPE_API_URL\": \"https://<your EntryScape API host>\", \"ENTRYSCAPE_AUTH_TOKEN\": \"your-session-token\" } } } } ``` From an unpacked download instead, the command is `\"command\": \"node\", \"args\": [\"/path/to/entryscape-mcp/dist/bin/entryscape-mcp.js\"]`. ### Claude Code The unpacked package is also a Claude Code plugin, so one install gives the server and the skills below together. Claude Code installs plugins from marketplaces, and the package carries a one-entry marketplace pointing at itself: ``` claude plugin marketplace add /path/to/entryscape-mcp claude plugin install entryscape@entryscape --scope user ``` The plugin passes `ENTRYSCAPE_API_URL`, `ENTRYSCAPE_AUTH_TOKEN`, `ENTRYSCAPE_ENTRYSTORE_HOST`, `ENTRYSCAPE_MCP_TAGS` and `ENTRYSCAPE_MCP_UPLOAD_ROOT` through from the shell Claude Code was started in, so set them there. To try the plugin for one session without installing it, start Claude Code with `--plugin-dir /path/to/entryscape-mcp`. ### Skills `skills/` in the package holds procedures that span several tools, in the Agent Skills format (a `SKILL.md` with `name` and `description`): which tools to call in which order, what to check between calls, and where to stop. Claude Code loads them from the plugin; other clients that read the format can be pointed at the directory. The `find` skill covers discovery, facets and selective metadata reads; `publish-dataset` takes a dataset from catalog to validated distribution with its file; `edit-metadata` changes an entry that already exists without dropping the rest of its graph, models included; `migrate-from-taskrunner` moves an integration off the deprecated Taskrunner API. Every tool a skill names is checked against this specification when the package is built. ## Deprecation Policy When endpoints or features are deprecated: 1. The operation is marked with `deprecated: true` in this spec 2. The operation description documents the replacement endpoint and sunset date 3. Deprecated endpoints remain functional for at least 6 months after announcement 4. The server returns a `Sunset` header with the planned removal date 5. After the sunset date, the endpoint may be removed in a future release
7
+
8
+ The version of the OpenAPI document: 1.3.0
9
+ Contact: contact@entryscape.com
10
+ Generated by OpenAPI Generator (https://openapi-generator.tech)
11
+
12
+ Do not edit the class manually.
13
+ """ # noqa: E501
14
+
15
+ from __future__ import annotations
16
+ import pprint
17
+ import re # noqa: F401
18
+ import json
19
+
20
+ from pydantic import BaseModel, ConfigDict, Field
21
+ from typing import Any, ClassVar, Dict, List, Optional
22
+ from typing_extensions import Annotated
23
+ from typing import Optional, Set
24
+ from typing_extensions import Self
25
+ from pydantic_core import to_jsonable_python
26
+
27
+
28
+ class JobStatusProgress(BaseModel):
29
+ """
30
+ Processing progress (only present when status is PROCESSING)
31
+ """ # noqa: E501
32
+
33
+ total: Optional[Annotated[int, Field(strict=True, ge=0)]] = Field(
34
+ default=None, description="Total items to process"
35
+ )
36
+ processed: Optional[Annotated[int, Field(strict=True, ge=0)]] = Field(
37
+ default=None, description="Items processed so far"
38
+ )
39
+ __properties: ClassVar[List[str]] = ["total", "processed"]
40
+
41
+ model_config = ConfigDict(
42
+ validate_by_name=True,
43
+ validate_by_alias=True,
44
+ validate_assignment=True,
45
+ protected_namespaces=(),
46
+ )
47
+
48
+ def to_str(self) -> str:
49
+ """Returns the string representation of the model using alias"""
50
+ return pprint.pformat(self.model_dump(by_alias=True))
51
+
52
+ def to_json(self) -> str:
53
+ """Returns the JSON representation of the model using alias"""
54
+ return json.dumps(to_jsonable_python(self.to_dict()))
55
+
56
+ @classmethod
57
+ def from_json(cls, json_str: str) -> Optional[Self]:
58
+ """Create an instance of JobStatusProgress from a JSON string"""
59
+ return cls.from_dict(json.loads(json_str))
60
+
61
+ def to_dict(self) -> Dict[str, Any]:
62
+ """Return the dictionary representation of the model using alias.
63
+
64
+ This has the following differences from calling pydantic's
65
+ `self.model_dump(by_alias=True)`:
66
+
67
+ * `None` is only added to the output dict for nullable fields that
68
+ were set at model initialization. Other fields with value `None`
69
+ are ignored.
70
+ """
71
+ excluded_fields: Set[str] = set([])
72
+
73
+ _dict = self.model_dump(
74
+ by_alias=True,
75
+ exclude=excluded_fields,
76
+ exclude_none=True,
77
+ )
78
+ return _dict
79
+
80
+ @classmethod
81
+ def from_dict(cls, obj: Optional[Dict[str, Any]]) -> Optional[Self]:
82
+ """Create an instance of JobStatusProgress from a dict"""
83
+ if obj is None:
84
+ return None
85
+
86
+ if not isinstance(obj, dict):
87
+ return cls.model_validate(obj)
88
+
89
+ # raise errors for additional fields in the input
90
+ for _key in obj.keys():
91
+ if _key not in cls.__properties:
92
+ raise ValueError(
93
+ "Error due to additional fields (not defined in JobStatusProgress) in the input: "
94
+ + _key
95
+ )
96
+
97
+ _obj = cls.model_validate(
98
+ {"total": obj.get("total"), "processed": obj.get("processed")}
99
+ )
100
+ return _obj
@@ -0,0 +1,37 @@
1
+ # coding: utf-8
2
+
3
+ """
4
+ EntryScape API
5
+
6
+ This API provides structured access to EntryScape data following DCAT-AP standards. All entity endpoints follow a consistent pattern: - GET /{entity} - List all entities - POST /{entity} - Create a new entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id} - Get entity reference info - DELETE /{entity}/{context_id}/{entry_id} - Delete an entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id}/metadata - Get raw RDF metadata - PUT /{entity}/{context_id}/{entry_id}/metadata - Replace raw RDF metadata (JSON-LD, Turtle, RDF/XML, or N-Triples passthrough) ## Reading and consistency Reads of a single entity — `GET /{entity}/{context_id}/{entry_id}` and its `/metadata` — go straight to the store and always reflect the latest write. Lists and search do not. They are answered from a search index that is updated asynchronously, so for a short interval after a write: - an entry that was just created may be missing from the list it belongs to, while reading it by id already works; - an entry that was just deleted may still appear; - `results` counts what the index holds, not what the store holds. Write a client that tolerates this: after creating an entry, use the id the create returned rather than searching for what you just wrote. `results` is also an upper bound rather than an exact count when the caller cannot read every hit (see the field's own description). Separately, responses are cached for 15 minutes by default, which is a second and unrelated source of staleness. A write invalidates the cache entries it affects, but a read that lands in the indexing gap can cache a list that does not yet show it. ## Authentication Most endpoints require an authenticated session. Reading public data works without authentication, while creating, updating, and deleting entities requires a valid user session. 1. **Log in** with `POST /auth/login`, supplying an EntryStore username and password. The response returns an `auth_token`. 2. **Send the token** on subsequent requests via the `X-Auth-Token` header. This is the recommended method for SDK and programmatic access. Browser clients can instead rely on the `auth_token` cookie, which the server sets automatically on login (`SameSite=Lax; Secure`). 3. **Inspect the session** with `GET /auth/whoami`, which returns the current user or an anonymous/guest identity when no valid token is supplied. 4. **Log out** with `POST /auth/logout` to invalidate the token and clear the cookie. ### Writes and CSRF Send the token as the `X-Auth-Token` **header** and there is nothing else to do: creates, updates and deletes work as they are, which is how the SDKs and the MCP server are built. The `auth_token` cookie is different. A cookie is attached by the browser automatically, so a state-changing request authenticated by it alone is what cross-site request forgery abuses, and those requests additionally need a double-submit token: read the `XSRF-TOKEN` cookie the server sets on any response and send its value back as the `X-XSRF-TOKEN` header. Without it the request is rejected with `403` before it reaches the endpoint. A custom header cannot be forged this way — cross-origin JavaScript cannot set one without a CORS preflight, which this API grants only to configured origins — so the header is the recommended path for anything that is not a browser session. ### App Tokens An app token identifies an integration. Create one with `POST /app-token` (unauthenticated). Creation requires an email address: the token starts in the `pending` state and a 6-digit code is emailed to the owner. Confirm the code with `POST /app-token/verify` to activate the token and receive its value, which is shown only once — store it securely. `GET /app-token/{app_token_id}` then returns its details and quota usage, authenticated by the token itself via the `X-App-Token` header. **The `X-App-Token` header is accepted only by `GET /app-token/{app_token_id}`.** No other operation reads it, and the read quota is recorded but not yet enforced: reading public data needs no token of any kind, and sending an app token with a read neither grants nor meters anything. Metered public read access is the intent of the two-token model, not a description of this release — see the `security` declared on each operation for what it actually accepts. ## SDKs Generated clients for Python, TypeScript, JavaScript and C# wrap every operation below, and each operation on this page shows the SDK call beside the `curl` command. Two of them install from a public registry: ``` pip install entryscape # Python npm install @entryscape/api-client # TypeScript and JavaScript ``` `@entryscape/api-client` ships an ESM and a CommonJS build, so `import` and `require()` both work and TypeScript is not required to use it — the name describes what it is written in, not what you have to write. There is a separate generated JavaScript SDK, and it is deliberately **not** on npm; this package is the npm client for both languages. Every SDK, including the C# and JavaScript ones, is also published as a tarball. The downloads are linked in the sidebar, they are the route to take when a registry is unreachable or a build has to vendor its dependencies, and each archive carries the SDK's own README: - **Python** — `pip install entryscape`, or `python-sdk.tar.gz`. - **TypeScript and JavaScript** — `npm install @entryscape/api-client`, or `typescript-sdk.tar.gz`. - **JavaScript (the separate generated client)** — not published to a registry, by design; `javascript-sdk.tar.gz` only. - **C#** — not published to NuGet yet; `csharp-sdk.tar.gz` only. - **MCP server** — `npx -y @entryscape/mcp-server`, or `mcp-server.tar.gz`. ## MCP Server A Model Context Protocol (MCP) server is generated from this specification and published alongside the SDKs (`@entryscape/mcp-server`), exposing the API as tools for AI assistants and agents. Each operation becomes one tool named after its `operationId` — `listDatasets`, `createCatalog`, `search`, `getJobStatus`. The `auth` operations are the exception: the server reads its token once at startup, so a `login` tool could install nothing and a `logout` tool would only invalidate the token the server was started with. On connect the server also hands the assistant a short set of rules that hold across every tool: a token is bound to one EntryStore instance, the search index lags a write, uploads finish as jobs. ### Install The server is on npm, and MCP servers are normally launched straight from there, so nothing has to be installed first: ``` npx -y @entryscape/mcp-server ``` `npm install -g @entryscape/mcp-server` works too and puts an `entryscape-mcp` binary on `PATH`. It is also listed in the MCP Registry as `com.entryscape/mcp-server`, which is where clients and marketplaces look it up. Without npm, download `mcp-server.tar.gz` from the SDK downloads and unpack it. The package ships prebuilt; install its runtime dependency once: ``` mkdir entryscape-mcp && tar -xzf mcp-server.tar.gz -C entryscape-mcp cd entryscape-mcp && npm install --omit=dev ``` ### Configure The server is a stdio MCP server configured through environment variables, read once at startup: - `ENTRYSCAPE_API_URL` — base URL of the API server, path included. Required: there is no default, and the server refuses to start without it. - `ENTRYSCAPE_AUTH_TOKEN` — a session token from `POST /auth/login`, sent as the `X-Auth-Token` header. Optional: without it reads see public entries and every write is refused. A token is valid only for the EntryStore instance that issued it. - `ENTRYSCAPE_ENTRYSTORE_HOST` — the EntryStore instance the API server should use, for example `dev.entryscape.com/store/`. Unset means the API server's own default. - `ENTRYSCAPE_MCP_UPLOAD_ROOT` — the directory the upload tools may read files from. **Unset means uploads are disabled**: `addFileToDistribution`, `replaceFileInDistribution` and `importTerminology` refuse and say so. - `ENTRYSCAPE_MCP_TAGS` — comma-separated tags to serve tools for, for example `catalog,dataset,distribution,search`. Unset serves every tool. The package's `README.md` lists the remaining variables (timeouts and size caps). Register the server with any MCP-capable client by adding it to the client's `mcpServers` configuration: ```json { \"mcpServers\": { \"entryscape\": { \"command\": \"npx\", \"args\": [\"-y\", \"@entryscape/mcp-server\"], \"env\": { \"ENTRYSCAPE_API_URL\": \"https://<your EntryScape API host>\", \"ENTRYSCAPE_AUTH_TOKEN\": \"your-session-token\" } } } } ``` From an unpacked download instead, the command is `\"command\": \"node\", \"args\": [\"/path/to/entryscape-mcp/dist/bin/entryscape-mcp.js\"]`. ### Claude Code The unpacked package is also a Claude Code plugin, so one install gives the server and the skills below together. Claude Code installs plugins from marketplaces, and the package carries a one-entry marketplace pointing at itself: ``` claude plugin marketplace add /path/to/entryscape-mcp claude plugin install entryscape@entryscape --scope user ``` The plugin passes `ENTRYSCAPE_API_URL`, `ENTRYSCAPE_AUTH_TOKEN`, `ENTRYSCAPE_ENTRYSTORE_HOST`, `ENTRYSCAPE_MCP_TAGS` and `ENTRYSCAPE_MCP_UPLOAD_ROOT` through from the shell Claude Code was started in, so set them there. To try the plugin for one session without installing it, start Claude Code with `--plugin-dir /path/to/entryscape-mcp`. ### Skills `skills/` in the package holds procedures that span several tools, in the Agent Skills format (a `SKILL.md` with `name` and `description`): which tools to call in which order, what to check between calls, and where to stop. Claude Code loads them from the plugin; other clients that read the format can be pointed at the directory. The `find` skill covers discovery, facets and selective metadata reads; `publish-dataset` takes a dataset from catalog to validated distribution with its file; `edit-metadata` changes an entry that already exists without dropping the rest of its graph, models included; `migrate-from-taskrunner` moves an integration off the deprecated Taskrunner API. Every tool a skill names is checked against this specification when the package is built. ## Deprecation Policy When endpoints or features are deprecated: 1. The operation is marked with `deprecated: true` in this spec 2. The operation description documents the replacement endpoint and sunset date 3. Deprecated endpoints remain functional for at least 6 months after announcement 4. The server returns a `Sunset` header with the planned removal date 5. After the sunset date, the endpoint may be removed in a future release
7
+
8
+ The version of the OpenAPI document: 1.3.0
9
+ Contact: contact@entryscape.com
10
+ Generated by OpenAPI Generator (https://openapi-generator.tech)
11
+
12
+ Do not edit the class manually.
13
+ """ # noqa: E501
14
+
15
+ from __future__ import annotations
16
+ import json
17
+ from enum import Enum
18
+ from typing_extensions import Self
19
+
20
+
21
+ class JobStatusValue(str, Enum):
22
+ """
23
+ Current status of an upload job: - PENDING: Job is queued and waiting to be processed - PROCESSING: Job is currently being processed - SUCCESS: Job completed successfully - FAILED: Job failed with an error
24
+ """
25
+
26
+ """
27
+ allowed enum values
28
+ """
29
+ Pending = "PENDING"
30
+ Processing = "PROCESSING"
31
+ Success = "SUCCESS"
32
+ Failed = "FAILED"
33
+
34
+ @classmethod
35
+ def from_json(cls, json_str: str) -> Self:
36
+ """Create an instance of JobStatusValue from a JSON string"""
37
+ return cls(json.loads(json_str))
@@ -0,0 +1,37 @@
1
+ # coding: utf-8
2
+
3
+ """
4
+ EntryScape API
5
+
6
+ This API provides structured access to EntryScape data following DCAT-AP standards. All entity endpoints follow a consistent pattern: - GET /{entity} - List all entities - POST /{entity} - Create a new entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id} - Get entity reference info - DELETE /{entity}/{context_id}/{entry_id} - Delete an entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id}/metadata - Get raw RDF metadata - PUT /{entity}/{context_id}/{entry_id}/metadata - Replace raw RDF metadata (JSON-LD, Turtle, RDF/XML, or N-Triples passthrough) ## Reading and consistency Reads of a single entity — `GET /{entity}/{context_id}/{entry_id}` and its `/metadata` — go straight to the store and always reflect the latest write. Lists and search do not. They are answered from a search index that is updated asynchronously, so for a short interval after a write: - an entry that was just created may be missing from the list it belongs to, while reading it by id already works; - an entry that was just deleted may still appear; - `results` counts what the index holds, not what the store holds. Write a client that tolerates this: after creating an entry, use the id the create returned rather than searching for what you just wrote. `results` is also an upper bound rather than an exact count when the caller cannot read every hit (see the field's own description). Separately, responses are cached for 15 minutes by default, which is a second and unrelated source of staleness. A write invalidates the cache entries it affects, but a read that lands in the indexing gap can cache a list that does not yet show it. ## Authentication Most endpoints require an authenticated session. Reading public data works without authentication, while creating, updating, and deleting entities requires a valid user session. 1. **Log in** with `POST /auth/login`, supplying an EntryStore username and password. The response returns an `auth_token`. 2. **Send the token** on subsequent requests via the `X-Auth-Token` header. This is the recommended method for SDK and programmatic access. Browser clients can instead rely on the `auth_token` cookie, which the server sets automatically on login (`SameSite=Lax; Secure`). 3. **Inspect the session** with `GET /auth/whoami`, which returns the current user or an anonymous/guest identity when no valid token is supplied. 4. **Log out** with `POST /auth/logout` to invalidate the token and clear the cookie. ### Writes and CSRF Send the token as the `X-Auth-Token` **header** and there is nothing else to do: creates, updates and deletes work as they are, which is how the SDKs and the MCP server are built. The `auth_token` cookie is different. A cookie is attached by the browser automatically, so a state-changing request authenticated by it alone is what cross-site request forgery abuses, and those requests additionally need a double-submit token: read the `XSRF-TOKEN` cookie the server sets on any response and send its value back as the `X-XSRF-TOKEN` header. Without it the request is rejected with `403` before it reaches the endpoint. A custom header cannot be forged this way — cross-origin JavaScript cannot set one without a CORS preflight, which this API grants only to configured origins — so the header is the recommended path for anything that is not a browser session. ### App Tokens An app token identifies an integration. Create one with `POST /app-token` (unauthenticated). Creation requires an email address: the token starts in the `pending` state and a 6-digit code is emailed to the owner. Confirm the code with `POST /app-token/verify` to activate the token and receive its value, which is shown only once — store it securely. `GET /app-token/{app_token_id}` then returns its details and quota usage, authenticated by the token itself via the `X-App-Token` header. **The `X-App-Token` header is accepted only by `GET /app-token/{app_token_id}`.** No other operation reads it, and the read quota is recorded but not yet enforced: reading public data needs no token of any kind, and sending an app token with a read neither grants nor meters anything. Metered public read access is the intent of the two-token model, not a description of this release — see the `security` declared on each operation for what it actually accepts. ## SDKs Generated clients for Python, TypeScript, JavaScript and C# wrap every operation below, and each operation on this page shows the SDK call beside the `curl` command. Two of them install from a public registry: ``` pip install entryscape # Python npm install @entryscape/api-client # TypeScript and JavaScript ``` `@entryscape/api-client` ships an ESM and a CommonJS build, so `import` and `require()` both work and TypeScript is not required to use it — the name describes what it is written in, not what you have to write. There is a separate generated JavaScript SDK, and it is deliberately **not** on npm; this package is the npm client for both languages. Every SDK, including the C# and JavaScript ones, is also published as a tarball. The downloads are linked in the sidebar, they are the route to take when a registry is unreachable or a build has to vendor its dependencies, and each archive carries the SDK's own README: - **Python** — `pip install entryscape`, or `python-sdk.tar.gz`. - **TypeScript and JavaScript** — `npm install @entryscape/api-client`, or `typescript-sdk.tar.gz`. - **JavaScript (the separate generated client)** — not published to a registry, by design; `javascript-sdk.tar.gz` only. - **C#** — not published to NuGet yet; `csharp-sdk.tar.gz` only. - **MCP server** — `npx -y @entryscape/mcp-server`, or `mcp-server.tar.gz`. ## MCP Server A Model Context Protocol (MCP) server is generated from this specification and published alongside the SDKs (`@entryscape/mcp-server`), exposing the API as tools for AI assistants and agents. Each operation becomes one tool named after its `operationId` — `listDatasets`, `createCatalog`, `search`, `getJobStatus`. The `auth` operations are the exception: the server reads its token once at startup, so a `login` tool could install nothing and a `logout` tool would only invalidate the token the server was started with. On connect the server also hands the assistant a short set of rules that hold across every tool: a token is bound to one EntryStore instance, the search index lags a write, uploads finish as jobs. ### Install The server is on npm, and MCP servers are normally launched straight from there, so nothing has to be installed first: ``` npx -y @entryscape/mcp-server ``` `npm install -g @entryscape/mcp-server` works too and puts an `entryscape-mcp` binary on `PATH`. It is also listed in the MCP Registry as `com.entryscape/mcp-server`, which is where clients and marketplaces look it up. Without npm, download `mcp-server.tar.gz` from the SDK downloads and unpack it. The package ships prebuilt; install its runtime dependency once: ``` mkdir entryscape-mcp && tar -xzf mcp-server.tar.gz -C entryscape-mcp cd entryscape-mcp && npm install --omit=dev ``` ### Configure The server is a stdio MCP server configured through environment variables, read once at startup: - `ENTRYSCAPE_API_URL` — base URL of the API server, path included. Required: there is no default, and the server refuses to start without it. - `ENTRYSCAPE_AUTH_TOKEN` — a session token from `POST /auth/login`, sent as the `X-Auth-Token` header. Optional: without it reads see public entries and every write is refused. A token is valid only for the EntryStore instance that issued it. - `ENTRYSCAPE_ENTRYSTORE_HOST` — the EntryStore instance the API server should use, for example `dev.entryscape.com/store/`. Unset means the API server's own default. - `ENTRYSCAPE_MCP_UPLOAD_ROOT` — the directory the upload tools may read files from. **Unset means uploads are disabled**: `addFileToDistribution`, `replaceFileInDistribution` and `importTerminology` refuse and say so. - `ENTRYSCAPE_MCP_TAGS` — comma-separated tags to serve tools for, for example `catalog,dataset,distribution,search`. Unset serves every tool. The package's `README.md` lists the remaining variables (timeouts and size caps). Register the server with any MCP-capable client by adding it to the client's `mcpServers` configuration: ```json { \"mcpServers\": { \"entryscape\": { \"command\": \"npx\", \"args\": [\"-y\", \"@entryscape/mcp-server\"], \"env\": { \"ENTRYSCAPE_API_URL\": \"https://<your EntryScape API host>\", \"ENTRYSCAPE_AUTH_TOKEN\": \"your-session-token\" } } } } ``` From an unpacked download instead, the command is `\"command\": \"node\", \"args\": [\"/path/to/entryscape-mcp/dist/bin/entryscape-mcp.js\"]`. ### Claude Code The unpacked package is also a Claude Code plugin, so one install gives the server and the skills below together. Claude Code installs plugins from marketplaces, and the package carries a one-entry marketplace pointing at itself: ``` claude plugin marketplace add /path/to/entryscape-mcp claude plugin install entryscape@entryscape --scope user ``` The plugin passes `ENTRYSCAPE_API_URL`, `ENTRYSCAPE_AUTH_TOKEN`, `ENTRYSCAPE_ENTRYSTORE_HOST`, `ENTRYSCAPE_MCP_TAGS` and `ENTRYSCAPE_MCP_UPLOAD_ROOT` through from the shell Claude Code was started in, so set them there. To try the plugin for one session without installing it, start Claude Code with `--plugin-dir /path/to/entryscape-mcp`. ### Skills `skills/` in the package holds procedures that span several tools, in the Agent Skills format (a `SKILL.md` with `name` and `description`): which tools to call in which order, what to check between calls, and where to stop. Claude Code loads them from the plugin; other clients that read the format can be pointed at the directory. The `find` skill covers discovery, facets and selective metadata reads; `publish-dataset` takes a dataset from catalog to validated distribution with its file; `edit-metadata` changes an entry that already exists without dropping the rest of its graph, models included; `migrate-from-taskrunner` moves an integration off the deprecated Taskrunner API. Every tool a skill names is checked against this specification when the package is built. ## Deprecation Policy When endpoints or features are deprecated: 1. The operation is marked with `deprecated: true` in this spec 2. The operation description documents the replacement endpoint and sunset date 3. Deprecated endpoints remain functional for at least 6 months after announcement 4. The server returns a `Sunset` header with the planned removal date 5. After the sunset date, the endpoint may be removed in a future release
7
+
8
+ The version of the OpenAPI document: 1.3.0
9
+ Contact: contact@entryscape.com
10
+ Generated by OpenAPI Generator (https://openapi-generator.tech)
11
+
12
+ Do not edit the class manually.
13
+ """ # noqa: E501
14
+
15
+ from __future__ import annotations
16
+ import json
17
+ from enum import Enum
18
+ from typing_extensions import Self
19
+
20
+
21
+ class JobType(str, Enum):
22
+ """
23
+ Type of asynchronous job: - ADD: Add a new file to a distribution (creates the file entry and links it) - REPLACE: Replace the content of an existing file entry - IMPORT_TERMINOLOGY: Import a SKOS terminology from an RDF file or URL - BUILD_MODEL: Build and export model artifacts into a specification
24
+ """
25
+
26
+ """
27
+ allowed enum values
28
+ """
29
+ ADD = "ADD"
30
+ REPLACE = "REPLACE"
31
+ IMPORT_TERMINOLOGY = "IMPORT_TERMINOLOGY"
32
+ BUILD_MODEL = "BUILD_MODEL"
33
+
34
+ @classmethod
35
+ def from_json(cls, json_str: str) -> Self:
36
+ """Create an instance of JobType from a JSON string"""
37
+ return cls(json.loads(json_str))
@@ -0,0 +1,37 @@
1
+ # coding: utf-8
2
+
3
+ """
4
+ EntryScape API
5
+
6
+ This API provides structured access to EntryScape data following DCAT-AP standards. All entity endpoints follow a consistent pattern: - GET /{entity} - List all entities - POST /{entity} - Create a new entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id} - Get entity reference info - DELETE /{entity}/{context_id}/{entry_id} - Delete an entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id}/metadata - Get raw RDF metadata - PUT /{entity}/{context_id}/{entry_id}/metadata - Replace raw RDF metadata (JSON-LD, Turtle, RDF/XML, or N-Triples passthrough) ## Reading and consistency Reads of a single entity — `GET /{entity}/{context_id}/{entry_id}` and its `/metadata` — go straight to the store and always reflect the latest write. Lists and search do not. They are answered from a search index that is updated asynchronously, so for a short interval after a write: - an entry that was just created may be missing from the list it belongs to, while reading it by id already works; - an entry that was just deleted may still appear; - `results` counts what the index holds, not what the store holds. Write a client that tolerates this: after creating an entry, use the id the create returned rather than searching for what you just wrote. `results` is also an upper bound rather than an exact count when the caller cannot read every hit (see the field's own description). Separately, responses are cached for 15 minutes by default, which is a second and unrelated source of staleness. A write invalidates the cache entries it affects, but a read that lands in the indexing gap can cache a list that does not yet show it. ## Authentication Most endpoints require an authenticated session. Reading public data works without authentication, while creating, updating, and deleting entities requires a valid user session. 1. **Log in** with `POST /auth/login`, supplying an EntryStore username and password. The response returns an `auth_token`. 2. **Send the token** on subsequent requests via the `X-Auth-Token` header. This is the recommended method for SDK and programmatic access. Browser clients can instead rely on the `auth_token` cookie, which the server sets automatically on login (`SameSite=Lax; Secure`). 3. **Inspect the session** with `GET /auth/whoami`, which returns the current user or an anonymous/guest identity when no valid token is supplied. 4. **Log out** with `POST /auth/logout` to invalidate the token and clear the cookie. ### Writes and CSRF Send the token as the `X-Auth-Token` **header** and there is nothing else to do: creates, updates and deletes work as they are, which is how the SDKs and the MCP server are built. The `auth_token` cookie is different. A cookie is attached by the browser automatically, so a state-changing request authenticated by it alone is what cross-site request forgery abuses, and those requests additionally need a double-submit token: read the `XSRF-TOKEN` cookie the server sets on any response and send its value back as the `X-XSRF-TOKEN` header. Without it the request is rejected with `403` before it reaches the endpoint. A custom header cannot be forged this way — cross-origin JavaScript cannot set one without a CORS preflight, which this API grants only to configured origins — so the header is the recommended path for anything that is not a browser session. ### App Tokens An app token identifies an integration. Create one with `POST /app-token` (unauthenticated). Creation requires an email address: the token starts in the `pending` state and a 6-digit code is emailed to the owner. Confirm the code with `POST /app-token/verify` to activate the token and receive its value, which is shown only once — store it securely. `GET /app-token/{app_token_id}` then returns its details and quota usage, authenticated by the token itself via the `X-App-Token` header. **The `X-App-Token` header is accepted only by `GET /app-token/{app_token_id}`.** No other operation reads it, and the read quota is recorded but not yet enforced: reading public data needs no token of any kind, and sending an app token with a read neither grants nor meters anything. Metered public read access is the intent of the two-token model, not a description of this release — see the `security` declared on each operation for what it actually accepts. ## SDKs Generated clients for Python, TypeScript, JavaScript and C# wrap every operation below, and each operation on this page shows the SDK call beside the `curl` command. Two of them install from a public registry: ``` pip install entryscape # Python npm install @entryscape/api-client # TypeScript and JavaScript ``` `@entryscape/api-client` ships an ESM and a CommonJS build, so `import` and `require()` both work and TypeScript is not required to use it — the name describes what it is written in, not what you have to write. There is a separate generated JavaScript SDK, and it is deliberately **not** on npm; this package is the npm client for both languages. Every SDK, including the C# and JavaScript ones, is also published as a tarball. The downloads are linked in the sidebar, they are the route to take when a registry is unreachable or a build has to vendor its dependencies, and each archive carries the SDK's own README: - **Python** — `pip install entryscape`, or `python-sdk.tar.gz`. - **TypeScript and JavaScript** — `npm install @entryscape/api-client`, or `typescript-sdk.tar.gz`. - **JavaScript (the separate generated client)** — not published to a registry, by design; `javascript-sdk.tar.gz` only. - **C#** — not published to NuGet yet; `csharp-sdk.tar.gz` only. - **MCP server** — `npx -y @entryscape/mcp-server`, or `mcp-server.tar.gz`. ## MCP Server A Model Context Protocol (MCP) server is generated from this specification and published alongside the SDKs (`@entryscape/mcp-server`), exposing the API as tools for AI assistants and agents. Each operation becomes one tool named after its `operationId` — `listDatasets`, `createCatalog`, `search`, `getJobStatus`. The `auth` operations are the exception: the server reads its token once at startup, so a `login` tool could install nothing and a `logout` tool would only invalidate the token the server was started with. On connect the server also hands the assistant a short set of rules that hold across every tool: a token is bound to one EntryStore instance, the search index lags a write, uploads finish as jobs. ### Install The server is on npm, and MCP servers are normally launched straight from there, so nothing has to be installed first: ``` npx -y @entryscape/mcp-server ``` `npm install -g @entryscape/mcp-server` works too and puts an `entryscape-mcp` binary on `PATH`. It is also listed in the MCP Registry as `com.entryscape/mcp-server`, which is where clients and marketplaces look it up. Without npm, download `mcp-server.tar.gz` from the SDK downloads and unpack it. The package ships prebuilt; install its runtime dependency once: ``` mkdir entryscape-mcp && tar -xzf mcp-server.tar.gz -C entryscape-mcp cd entryscape-mcp && npm install --omit=dev ``` ### Configure The server is a stdio MCP server configured through environment variables, read once at startup: - `ENTRYSCAPE_API_URL` — base URL of the API server, path included. Required: there is no default, and the server refuses to start without it. - `ENTRYSCAPE_AUTH_TOKEN` — a session token from `POST /auth/login`, sent as the `X-Auth-Token` header. Optional: without it reads see public entries and every write is refused. A token is valid only for the EntryStore instance that issued it. - `ENTRYSCAPE_ENTRYSTORE_HOST` — the EntryStore instance the API server should use, for example `dev.entryscape.com/store/`. Unset means the API server's own default. - `ENTRYSCAPE_MCP_UPLOAD_ROOT` — the directory the upload tools may read files from. **Unset means uploads are disabled**: `addFileToDistribution`, `replaceFileInDistribution` and `importTerminology` refuse and say so. - `ENTRYSCAPE_MCP_TAGS` — comma-separated tags to serve tools for, for example `catalog,dataset,distribution,search`. Unset serves every tool. The package's `README.md` lists the remaining variables (timeouts and size caps). Register the server with any MCP-capable client by adding it to the client's `mcpServers` configuration: ```json { \"mcpServers\": { \"entryscape\": { \"command\": \"npx\", \"args\": [\"-y\", \"@entryscape/mcp-server\"], \"env\": { \"ENTRYSCAPE_API_URL\": \"https://<your EntryScape API host>\", \"ENTRYSCAPE_AUTH_TOKEN\": \"your-session-token\" } } } } ``` From an unpacked download instead, the command is `\"command\": \"node\", \"args\": [\"/path/to/entryscape-mcp/dist/bin/entryscape-mcp.js\"]`. ### Claude Code The unpacked package is also a Claude Code plugin, so one install gives the server and the skills below together. Claude Code installs plugins from marketplaces, and the package carries a one-entry marketplace pointing at itself: ``` claude plugin marketplace add /path/to/entryscape-mcp claude plugin install entryscape@entryscape --scope user ``` The plugin passes `ENTRYSCAPE_API_URL`, `ENTRYSCAPE_AUTH_TOKEN`, `ENTRYSCAPE_ENTRYSTORE_HOST`, `ENTRYSCAPE_MCP_TAGS` and `ENTRYSCAPE_MCP_UPLOAD_ROOT` through from the shell Claude Code was started in, so set them there. To try the plugin for one session without installing it, start Claude Code with `--plugin-dir /path/to/entryscape-mcp`. ### Skills `skills/` in the package holds procedures that span several tools, in the Agent Skills format (a `SKILL.md` with `name` and `description`): which tools to call in which order, what to check between calls, and where to stop. Claude Code loads them from the plugin; other clients that read the format can be pointed at the directory. The `find` skill covers discovery, facets and selective metadata reads; `publish-dataset` takes a dataset from catalog to validated distribution with its file; `edit-metadata` changes an entry that already exists without dropping the rest of its graph, models included; `migrate-from-taskrunner` moves an integration off the deprecated Taskrunner API. Every tool a skill names is checked against this specification when the package is built. ## Deprecation Policy When endpoints or features are deprecated: 1. The operation is marked with `deprecated: true` in this spec 2. The operation description documents the replacement endpoint and sunset date 3. Deprecated endpoints remain functional for at least 6 months after announcement 4. The server returns a `Sunset` header with the planned removal date 5. After the sunset date, the endpoint may be removed in a future release
7
+
8
+ The version of the OpenAPI document: 1.3.0
9
+ Contact: contact@entryscape.com
10
+ Generated by OpenAPI Generator (https://openapi-generator.tech)
11
+
12
+ Do not edit the class manually.
13
+ """ # noqa: E501
14
+
15
+ from __future__ import annotations
16
+ import json
17
+ from enum import Enum
18
+ from typing_extensions import Self
19
+
20
+
21
+ class ListCatalogsEntryTypeParameter(str, Enum):
22
+ """
23
+ ListCatalogsEntryTypeParameter
24
+ """
25
+
26
+ """
27
+ allowed enum values
28
+ """
29
+ LOCAL = "Local"
30
+ LINK = "Link"
31
+ REFERENCE = "Reference"
32
+ LINKREFERENCE = "LinkReference"
33
+
34
+ @classmethod
35
+ def from_json(cls, json_str: str) -> Self:
36
+ """Create an instance of ListCatalogsEntryTypeParameter from a JSON string"""
37
+ return cls(json.loads(json_str))
@@ -0,0 +1,44 @@
1
+ # coding: utf-8
2
+
3
+ """
4
+ EntryScape API
5
+
6
+ This API provides structured access to EntryScape data following DCAT-AP standards. All entity endpoints follow a consistent pattern: - GET /{entity} - List all entities - POST /{entity} - Create a new entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id} - Get entity reference info - DELETE /{entity}/{context_id}/{entry_id} - Delete an entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id}/metadata - Get raw RDF metadata - PUT /{entity}/{context_id}/{entry_id}/metadata - Replace raw RDF metadata (JSON-LD, Turtle, RDF/XML, or N-Triples passthrough) ## Reading and consistency Reads of a single entity — `GET /{entity}/{context_id}/{entry_id}` and its `/metadata` — go straight to the store and always reflect the latest write. Lists and search do not. They are answered from a search index that is updated asynchronously, so for a short interval after a write: - an entry that was just created may be missing from the list it belongs to, while reading it by id already works; - an entry that was just deleted may still appear; - `results` counts what the index holds, not what the store holds. Write a client that tolerates this: after creating an entry, use the id the create returned rather than searching for what you just wrote. `results` is also an upper bound rather than an exact count when the caller cannot read every hit (see the field's own description). Separately, responses are cached for 15 minutes by default, which is a second and unrelated source of staleness. A write invalidates the cache entries it affects, but a read that lands in the indexing gap can cache a list that does not yet show it. ## Authentication Most endpoints require an authenticated session. Reading public data works without authentication, while creating, updating, and deleting entities requires a valid user session. 1. **Log in** with `POST /auth/login`, supplying an EntryStore username and password. The response returns an `auth_token`. 2. **Send the token** on subsequent requests via the `X-Auth-Token` header. This is the recommended method for SDK and programmatic access. Browser clients can instead rely on the `auth_token` cookie, which the server sets automatically on login (`SameSite=Lax; Secure`). 3. **Inspect the session** with `GET /auth/whoami`, which returns the current user or an anonymous/guest identity when no valid token is supplied. 4. **Log out** with `POST /auth/logout` to invalidate the token and clear the cookie. ### Writes and CSRF Send the token as the `X-Auth-Token` **header** and there is nothing else to do: creates, updates and deletes work as they are, which is how the SDKs and the MCP server are built. The `auth_token` cookie is different. A cookie is attached by the browser automatically, so a state-changing request authenticated by it alone is what cross-site request forgery abuses, and those requests additionally need a double-submit token: read the `XSRF-TOKEN` cookie the server sets on any response and send its value back as the `X-XSRF-TOKEN` header. Without it the request is rejected with `403` before it reaches the endpoint. A custom header cannot be forged this way — cross-origin JavaScript cannot set one without a CORS preflight, which this API grants only to configured origins — so the header is the recommended path for anything that is not a browser session. ### App Tokens An app token identifies an integration. Create one with `POST /app-token` (unauthenticated). Creation requires an email address: the token starts in the `pending` state and a 6-digit code is emailed to the owner. Confirm the code with `POST /app-token/verify` to activate the token and receive its value, which is shown only once — store it securely. `GET /app-token/{app_token_id}` then returns its details and quota usage, authenticated by the token itself via the `X-App-Token` header. **The `X-App-Token` header is accepted only by `GET /app-token/{app_token_id}`.** No other operation reads it, and the read quota is recorded but not yet enforced: reading public data needs no token of any kind, and sending an app token with a read neither grants nor meters anything. Metered public read access is the intent of the two-token model, not a description of this release — see the `security` declared on each operation for what it actually accepts. ## SDKs Generated clients for Python, TypeScript, JavaScript and C# wrap every operation below, and each operation on this page shows the SDK call beside the `curl` command. Two of them install from a public registry: ``` pip install entryscape # Python npm install @entryscape/api-client # TypeScript and JavaScript ``` `@entryscape/api-client` ships an ESM and a CommonJS build, so `import` and `require()` both work and TypeScript is not required to use it — the name describes what it is written in, not what you have to write. There is a separate generated JavaScript SDK, and it is deliberately **not** on npm; this package is the npm client for both languages. Every SDK, including the C# and JavaScript ones, is also published as a tarball. The downloads are linked in the sidebar, they are the route to take when a registry is unreachable or a build has to vendor its dependencies, and each archive carries the SDK's own README: - **Python** — `pip install entryscape`, or `python-sdk.tar.gz`. - **TypeScript and JavaScript** — `npm install @entryscape/api-client`, or `typescript-sdk.tar.gz`. - **JavaScript (the separate generated client)** — not published to a registry, by design; `javascript-sdk.tar.gz` only. - **C#** — not published to NuGet yet; `csharp-sdk.tar.gz` only. - **MCP server** — `npx -y @entryscape/mcp-server`, or `mcp-server.tar.gz`. ## MCP Server A Model Context Protocol (MCP) server is generated from this specification and published alongside the SDKs (`@entryscape/mcp-server`), exposing the API as tools for AI assistants and agents. Each operation becomes one tool named after its `operationId` — `listDatasets`, `createCatalog`, `search`, `getJobStatus`. The `auth` operations are the exception: the server reads its token once at startup, so a `login` tool could install nothing and a `logout` tool would only invalidate the token the server was started with. On connect the server also hands the assistant a short set of rules that hold across every tool: a token is bound to one EntryStore instance, the search index lags a write, uploads finish as jobs. ### Install The server is on npm, and MCP servers are normally launched straight from there, so nothing has to be installed first: ``` npx -y @entryscape/mcp-server ``` `npm install -g @entryscape/mcp-server` works too and puts an `entryscape-mcp` binary on `PATH`. It is also listed in the MCP Registry as `com.entryscape/mcp-server`, which is where clients and marketplaces look it up. Without npm, download `mcp-server.tar.gz` from the SDK downloads and unpack it. The package ships prebuilt; install its runtime dependency once: ``` mkdir entryscape-mcp && tar -xzf mcp-server.tar.gz -C entryscape-mcp cd entryscape-mcp && npm install --omit=dev ``` ### Configure The server is a stdio MCP server configured through environment variables, read once at startup: - `ENTRYSCAPE_API_URL` — base URL of the API server, path included. Required: there is no default, and the server refuses to start without it. - `ENTRYSCAPE_AUTH_TOKEN` — a session token from `POST /auth/login`, sent as the `X-Auth-Token` header. Optional: without it reads see public entries and every write is refused. A token is valid only for the EntryStore instance that issued it. - `ENTRYSCAPE_ENTRYSTORE_HOST` — the EntryStore instance the API server should use, for example `dev.entryscape.com/store/`. Unset means the API server's own default. - `ENTRYSCAPE_MCP_UPLOAD_ROOT` — the directory the upload tools may read files from. **Unset means uploads are disabled**: `addFileToDistribution`, `replaceFileInDistribution` and `importTerminology` refuse and say so. - `ENTRYSCAPE_MCP_TAGS` — comma-separated tags to serve tools for, for example `catalog,dataset,distribution,search`. Unset serves every tool. The package's `README.md` lists the remaining variables (timeouts and size caps). Register the server with any MCP-capable client by adding it to the client's `mcpServers` configuration: ```json { \"mcpServers\": { \"entryscape\": { \"command\": \"npx\", \"args\": [\"-y\", \"@entryscape/mcp-server\"], \"env\": { \"ENTRYSCAPE_API_URL\": \"https://<your EntryScape API host>\", \"ENTRYSCAPE_AUTH_TOKEN\": \"your-session-token\" } } } } ``` From an unpacked download instead, the command is `\"command\": \"node\", \"args\": [\"/path/to/entryscape-mcp/dist/bin/entryscape-mcp.js\"]`. ### Claude Code The unpacked package is also a Claude Code plugin, so one install gives the server and the skills below together. Claude Code installs plugins from marketplaces, and the package carries a one-entry marketplace pointing at itself: ``` claude plugin marketplace add /path/to/entryscape-mcp claude plugin install entryscape@entryscape --scope user ``` The plugin passes `ENTRYSCAPE_API_URL`, `ENTRYSCAPE_AUTH_TOKEN`, `ENTRYSCAPE_ENTRYSTORE_HOST`, `ENTRYSCAPE_MCP_TAGS` and `ENTRYSCAPE_MCP_UPLOAD_ROOT` through from the shell Claude Code was started in, so set them there. To try the plugin for one session without installing it, start Claude Code with `--plugin-dir /path/to/entryscape-mcp`. ### Skills `skills/` in the package holds procedures that span several tools, in the Agent Skills format (a `SKILL.md` with `name` and `description`): which tools to call in which order, what to check between calls, and where to stop. Claude Code loads them from the plugin; other clients that read the format can be pointed at the directory. The `find` skill covers discovery, facets and selective metadata reads; `publish-dataset` takes a dataset from catalog to validated distribution with its file; `edit-metadata` changes an entry that already exists without dropping the rest of its graph, models included; `migrate-from-taskrunner` moves an integration off the deprecated Taskrunner API. Every tool a skill names is checked against this specification when the package is built. ## Deprecation Policy When endpoints or features are deprecated: 1. The operation is marked with `deprecated: true` in this spec 2. The operation description documents the replacement endpoint and sunset date 3. Deprecated endpoints remain functional for at least 6 months after announcement 4. The server returns a `Sunset` header with the planned removal date 5. After the sunset date, the endpoint may be removed in a future release
7
+
8
+ The version of the OpenAPI document: 1.3.0
9
+ Contact: contact@entryscape.com
10
+ Generated by OpenAPI Generator (https://openapi-generator.tech)
11
+
12
+ Do not edit the class manually.
13
+ """ # noqa: E501
14
+
15
+ from __future__ import annotations
16
+ import json
17
+ from enum import Enum
18
+ from typing_extensions import Self
19
+
20
+
21
+ class ListCatalogsGraphTypeParameter(str, Enum):
22
+ """
23
+ ListCatalogsGraphTypeParameter
24
+ """
25
+
26
+ """
27
+ allowed enum values
28
+ """
29
+ NONE = "None"
30
+ CONTEXT = "Context"
31
+ SYSTEMCONTEXT = "Systemcontext"
32
+ USER = "User"
33
+ GROUP = "Group"
34
+ LIST = "List"
35
+ RESULTLIST = "Resultlist"
36
+ GRAPH = "Graph"
37
+ STRING = "String"
38
+ PIPELINE = "Pipeline"
39
+ PIPELINERESULT = "PipelineResult"
40
+
41
+ @classmethod
42
+ def from_json(cls, json_str: str) -> Self:
43
+ """Create an instance of ListCatalogsGraphTypeParameter from a JSON string"""
44
+ return cls(json.loads(json_str))
@@ -0,0 +1,37 @@
1
+ # coding: utf-8
2
+
3
+ """
4
+ EntryScape API
5
+
6
+ This API provides structured access to EntryScape data following DCAT-AP standards. All entity endpoints follow a consistent pattern: - GET /{entity} - List all entities - POST /{entity} - Create a new entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id} - Get entity reference info - DELETE /{entity}/{context_id}/{entry_id} - Delete an entity (DCAT types only) - GET /{entity}/{context_id}/{entry_id}/metadata - Get raw RDF metadata - PUT /{entity}/{context_id}/{entry_id}/metadata - Replace raw RDF metadata (JSON-LD, Turtle, RDF/XML, or N-Triples passthrough) ## Reading and consistency Reads of a single entity — `GET /{entity}/{context_id}/{entry_id}` and its `/metadata` — go straight to the store and always reflect the latest write. Lists and search do not. They are answered from a search index that is updated asynchronously, so for a short interval after a write: - an entry that was just created may be missing from the list it belongs to, while reading it by id already works; - an entry that was just deleted may still appear; - `results` counts what the index holds, not what the store holds. Write a client that tolerates this: after creating an entry, use the id the create returned rather than searching for what you just wrote. `results` is also an upper bound rather than an exact count when the caller cannot read every hit (see the field's own description). Separately, responses are cached for 15 minutes by default, which is a second and unrelated source of staleness. A write invalidates the cache entries it affects, but a read that lands in the indexing gap can cache a list that does not yet show it. ## Authentication Most endpoints require an authenticated session. Reading public data works without authentication, while creating, updating, and deleting entities requires a valid user session. 1. **Log in** with `POST /auth/login`, supplying an EntryStore username and password. The response returns an `auth_token`. 2. **Send the token** on subsequent requests via the `X-Auth-Token` header. This is the recommended method for SDK and programmatic access. Browser clients can instead rely on the `auth_token` cookie, which the server sets automatically on login (`SameSite=Lax; Secure`). 3. **Inspect the session** with `GET /auth/whoami`, which returns the current user or an anonymous/guest identity when no valid token is supplied. 4. **Log out** with `POST /auth/logout` to invalidate the token and clear the cookie. ### Writes and CSRF Send the token as the `X-Auth-Token` **header** and there is nothing else to do: creates, updates and deletes work as they are, which is how the SDKs and the MCP server are built. The `auth_token` cookie is different. A cookie is attached by the browser automatically, so a state-changing request authenticated by it alone is what cross-site request forgery abuses, and those requests additionally need a double-submit token: read the `XSRF-TOKEN` cookie the server sets on any response and send its value back as the `X-XSRF-TOKEN` header. Without it the request is rejected with `403` before it reaches the endpoint. A custom header cannot be forged this way — cross-origin JavaScript cannot set one without a CORS preflight, which this API grants only to configured origins — so the header is the recommended path for anything that is not a browser session. ### App Tokens An app token identifies an integration. Create one with `POST /app-token` (unauthenticated). Creation requires an email address: the token starts in the `pending` state and a 6-digit code is emailed to the owner. Confirm the code with `POST /app-token/verify` to activate the token and receive its value, which is shown only once — store it securely. `GET /app-token/{app_token_id}` then returns its details and quota usage, authenticated by the token itself via the `X-App-Token` header. **The `X-App-Token` header is accepted only by `GET /app-token/{app_token_id}`.** No other operation reads it, and the read quota is recorded but not yet enforced: reading public data needs no token of any kind, and sending an app token with a read neither grants nor meters anything. Metered public read access is the intent of the two-token model, not a description of this release — see the `security` declared on each operation for what it actually accepts. ## SDKs Generated clients for Python, TypeScript, JavaScript and C# wrap every operation below, and each operation on this page shows the SDK call beside the `curl` command. Two of them install from a public registry: ``` pip install entryscape # Python npm install @entryscape/api-client # TypeScript and JavaScript ``` `@entryscape/api-client` ships an ESM and a CommonJS build, so `import` and `require()` both work and TypeScript is not required to use it — the name describes what it is written in, not what you have to write. There is a separate generated JavaScript SDK, and it is deliberately **not** on npm; this package is the npm client for both languages. Every SDK, including the C# and JavaScript ones, is also published as a tarball. The downloads are linked in the sidebar, they are the route to take when a registry is unreachable or a build has to vendor its dependencies, and each archive carries the SDK's own README: - **Python** — `pip install entryscape`, or `python-sdk.tar.gz`. - **TypeScript and JavaScript** — `npm install @entryscape/api-client`, or `typescript-sdk.tar.gz`. - **JavaScript (the separate generated client)** — not published to a registry, by design; `javascript-sdk.tar.gz` only. - **C#** — not published to NuGet yet; `csharp-sdk.tar.gz` only. - **MCP server** — `npx -y @entryscape/mcp-server`, or `mcp-server.tar.gz`. ## MCP Server A Model Context Protocol (MCP) server is generated from this specification and published alongside the SDKs (`@entryscape/mcp-server`), exposing the API as tools for AI assistants and agents. Each operation becomes one tool named after its `operationId` — `listDatasets`, `createCatalog`, `search`, `getJobStatus`. The `auth` operations are the exception: the server reads its token once at startup, so a `login` tool could install nothing and a `logout` tool would only invalidate the token the server was started with. On connect the server also hands the assistant a short set of rules that hold across every tool: a token is bound to one EntryStore instance, the search index lags a write, uploads finish as jobs. ### Install The server is on npm, and MCP servers are normally launched straight from there, so nothing has to be installed first: ``` npx -y @entryscape/mcp-server ``` `npm install -g @entryscape/mcp-server` works too and puts an `entryscape-mcp` binary on `PATH`. It is also listed in the MCP Registry as `com.entryscape/mcp-server`, which is where clients and marketplaces look it up. Without npm, download `mcp-server.tar.gz` from the SDK downloads and unpack it. The package ships prebuilt; install its runtime dependency once: ``` mkdir entryscape-mcp && tar -xzf mcp-server.tar.gz -C entryscape-mcp cd entryscape-mcp && npm install --omit=dev ``` ### Configure The server is a stdio MCP server configured through environment variables, read once at startup: - `ENTRYSCAPE_API_URL` — base URL of the API server, path included. Required: there is no default, and the server refuses to start without it. - `ENTRYSCAPE_AUTH_TOKEN` — a session token from `POST /auth/login`, sent as the `X-Auth-Token` header. Optional: without it reads see public entries and every write is refused. A token is valid only for the EntryStore instance that issued it. - `ENTRYSCAPE_ENTRYSTORE_HOST` — the EntryStore instance the API server should use, for example `dev.entryscape.com/store/`. Unset means the API server's own default. - `ENTRYSCAPE_MCP_UPLOAD_ROOT` — the directory the upload tools may read files from. **Unset means uploads are disabled**: `addFileToDistribution`, `replaceFileInDistribution` and `importTerminology` refuse and say so. - `ENTRYSCAPE_MCP_TAGS` — comma-separated tags to serve tools for, for example `catalog,dataset,distribution,search`. Unset serves every tool. The package's `README.md` lists the remaining variables (timeouts and size caps). Register the server with any MCP-capable client by adding it to the client's `mcpServers` configuration: ```json { \"mcpServers\": { \"entryscape\": { \"command\": \"npx\", \"args\": [\"-y\", \"@entryscape/mcp-server\"], \"env\": { \"ENTRYSCAPE_API_URL\": \"https://<your EntryScape API host>\", \"ENTRYSCAPE_AUTH_TOKEN\": \"your-session-token\" } } } } ``` From an unpacked download instead, the command is `\"command\": \"node\", \"args\": [\"/path/to/entryscape-mcp/dist/bin/entryscape-mcp.js\"]`. ### Claude Code The unpacked package is also a Claude Code plugin, so one install gives the server and the skills below together. Claude Code installs plugins from marketplaces, and the package carries a one-entry marketplace pointing at itself: ``` claude plugin marketplace add /path/to/entryscape-mcp claude plugin install entryscape@entryscape --scope user ``` The plugin passes `ENTRYSCAPE_API_URL`, `ENTRYSCAPE_AUTH_TOKEN`, `ENTRYSCAPE_ENTRYSTORE_HOST`, `ENTRYSCAPE_MCP_TAGS` and `ENTRYSCAPE_MCP_UPLOAD_ROOT` through from the shell Claude Code was started in, so set them there. To try the plugin for one session without installing it, start Claude Code with `--plugin-dir /path/to/entryscape-mcp`. ### Skills `skills/` in the package holds procedures that span several tools, in the Agent Skills format (a `SKILL.md` with `name` and `description`): which tools to call in which order, what to check between calls, and where to stop. Claude Code loads them from the plugin; other clients that read the format can be pointed at the directory. The `find` skill covers discovery, facets and selective metadata reads; `publish-dataset` takes a dataset from catalog to validated distribution with its file; `edit-metadata` changes an entry that already exists without dropping the rest of its graph, models included; `migrate-from-taskrunner` moves an integration off the deprecated Taskrunner API. Every tool a skill names is checked against this specification when the package is built. ## Deprecation Policy When endpoints or features are deprecated: 1. The operation is marked with `deprecated: true` in this spec 2. The operation description documents the replacement endpoint and sunset date 3. Deprecated endpoints remain functional for at least 6 months after announcement 4. The server returns a `Sunset` header with the planned removal date 5. After the sunset date, the endpoint may be removed in a future release
7
+
8
+ The version of the OpenAPI document: 1.3.0
9
+ Contact: contact@entryscape.com
10
+ Generated by OpenAPI Generator (https://openapi-generator.tech)
11
+
12
+ Do not edit the class manually.
13
+ """ # noqa: E501
14
+
15
+ from __future__ import annotations
16
+ import json
17
+ from enum import Enum
18
+ from typing_extensions import Self
19
+
20
+
21
+ class ListCatalogsResourceTypeParameter(str, Enum):
22
+ """
23
+ ListCatalogsResourceTypeParameter
24
+ """
25
+
26
+ """
27
+ allowed enum values
28
+ """
29
+ INFORMATION = "Information"
30
+ RESOLVABLE = "Resolvable"
31
+ NAMED = "Named"
32
+ UNKNOWN = "Unknown"
33
+
34
+ @classmethod
35
+ def from_json(cls, json_str: str) -> Self:
36
+ """Create an instance of ListCatalogsResourceTypeParameter from a JSON string"""
37
+ return cls(json.loads(json_str))