@lapage/strapi-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.3
Disambiguation5/5
Each tool targets a distinct resource and action: health check, generic request, content types (list/schema), entries CRUD, and media operations. The overlapping upload tools are differentiated by source (URL vs local file), and the generic strapi_request is clearly scoped to custom endpoints.
Naming Consistency5/5
All tools follow a consistent snake_case pattern starting with 'strapi_', followed by a verb (list, get, create, update, delete, upload) and an object (content_types, entries, media). Even compound names like upload_media_from_url maintain a regular structure.
Tool Count5/5
With 15 tools, the server covers health, content type introspection, entry lifecycle, and media management without being bloated. Each tool serves a clear purpose within the Strapi domain, and the count falls well within the ideal 3-15 range.
Completeness4/5
The server provides comprehensive CRUD for both entries and media, plus schema access and a generic request fallback for custom endpoints. Minor gaps exist, such as no explicit publish/unpublish tool (though update_entry may handle it) and no dedicated filtering/search tool, but these are workable via list_entries parameters or strapi_request.
Average 3.5/5 across 15 of 15 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only restates the action implied by the name, offering no insights into side effects, authentication requirements, response shape, or any constraints. This is essentially a tautology with no added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, with no wasted words. It is appropriately concise for the amount of information it conveys. However, it borders on under-specification, lacking any explanatory context, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no annotations and no output schema, the description is not complete enough. It does not explain return values, error cases, or how this fits into the Strapi API workflow. The rich sibling list and schema partially compensate, but the description itself fails to provide situational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, including examples for queryJson and contentType. According to the rubric, high schema coverage yields a baseline of 3. The description itself adds no parameter-level meaning, so it neither improves nor worsens the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a Strapi entry using the REST API.' It uses a specific verb ('create') and identifies the resource ('Strapi entry'), which distinguishes it from sibling tools like strapi_update_entry or strapi_delete_entry. However, it lacks additional details such as the required contentType or data structure, so it is not as rich as a top-tier example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusion criteria, or alternatives like strapi_request for custom operations. The phrase 'using the REST API' hints at a mechanism but not at decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It only states the action ('check') but does not specify return values, error handling, side effects, or authentication requirements, leaving the agent uncertain about the outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check, the description covers the core purpose, but omits return value/error semantics. Without an output schema, this is a gap, though the simplicity of the tool mitigates the severity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is complete by default. The baseline of 4 applies; the description adds nothing necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'check' and resource 'configured Strapi server', clearly stating the purpose of verifying reachability. However, it does not differentiate from sibling tools like strapi_request, which could also be used for connectivity checks, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as strapi_request. The description only states what it does, not the appropriate context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action ('delete') without mentioning permanence, side effects on entries referencing the file, or error handling. These gaps are material for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous words. It is front-loaded with the action and resource, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one fully-described parameter, no output schema), the description is minimally adequate. However, it lacks context about the behavioral consequences of deletion and does not explain what the response will look like, which would be expected for a complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the fileId parameter is already described as 'Numeric Strapi upload file id.' The tool description adds no additional meaning beyond the schema, simply restating 'by file id.' Per the rubric, high coverage yields a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Delete a Strapi Media Library file by file id.' It uses a specific verb and resource, and clarifies the key parameter (file id), which distinguishes it from sibling tools like strapi_delete_entry (which deletes entries) and media update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not specify scenarios, prerequisites, or mention that related tools (e.g., strapi_update_media_info) are for modification rather than deletion. The description is purely functional and lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the authentication requirement (STRAPI_ADMIN_TOKEN or API token), which is useful context. However, it does not describe the return structure, potential errors, or any other behavioral aspects like rate limits or side effects. For a read-only get schema tool, the disclosed auth requirement adds some transparency but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant content. It front-loads the main action and then provides the auth requirement, which is directly relevant for invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema, no annotations), the description covers the core purpose and auth requirement. However, it lacks any indication of the response format (e.g., that it returns a JSON object representing the schema) and does not mention error scenarios. This is sufficient for a basic tool but not rich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the single parameter 'uid' is fully described with an example. The description adds no extra parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a content type schema via the content-manager API' with a specific verb and resource. It does not explicitly contrast with sibling tools like strapi_list_content_types or strapi_get_entry, but the resource 'content type schema' is distinct enough to infer its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It mentions the auth requirement but lacks any comparison with sibling tools or context for selection, such as 'use this to fetch schema definition rather than listing entries.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lacks important behavioral details such as pagination behavior (does it return all entries at once or a limited page?), default page size, or the effect of queryJson on results. There is no mention of response shape or error behavior, leaving key operational aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that front-loads the action and resource. Every word is meaningful, with no redundant phrasing. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and full schema coverage, giving a minimum viable explanation. However, the absence of an output schema and missing behavioral details (like pagination) make it incomplete for an agent to fully anticipate the tool's response and limitations. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for both parameters (contentType and queryJson), which already explains their meaning. The tool description adds no extra parameter-level detail, so the baseline of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'entries for a Strapi collection type', accurately conveying what the tool does. It distinguishes itself from sibling tools like 'strapi_get_entry' (single entry) and 'strapi_list_content_types' (schemas, not entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention that this is for multiple entries while 'strapi_get_entry' is for a single entry, nor does it provide any exclusions or prerequisites. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds the auth requirement (STRAPI_ADMIN_TOKEN or API token), which is useful. However, it does not clarify the response format, pagination, or explicitly state that the operation is read-only, leaving gaps in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word serves a purpose. No unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter listing tool with no output schema and no annotations, the description covers purpose and auth but omits return value details and potential limitations (e.g., whether it returns all content types or only accessible ones). It is minimally complete but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. Per the baseline for 0 parameters, the description need not add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Strapi content types via the content-manager API, which is a specific verb and resource. It is distinct from sibling tools that fetch schemas or entries, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like strapi_get_content_type_schema or strapi_list_entries. The description only mentions the auth requirement, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions the endpoint, omitting what the response contains, pagination defaults, or any read-only guarantees. This leaves critical execution details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the action and resource, efficiently conveying the primary purpose in the fewest words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should explain return format, pagination, and relationship to other media tools. It only provides the endpoint and basic action, leaving the agent underinformed for robust invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single queryJson parameter is fully described in the schema with an example, giving it 100% coverage. The tool description adds no extra meaning beyond the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Strapi Media Library files using the /api/upload/files endpoint. It distinguishes this from sibling tools like get_media or upload_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing media files but does not explicitly contrast with get_media for individual files or provide scenarios where this tool is preferred. It lacks explicit 'when to use' guidance, relying on the tool name and endpoint to convey context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the operation and does not describe return format, error behavior, or whether it's read-only. While 'get' implies read-only, the description lacks any explicit caveats or outcome details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It communicates the core action and parameter efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description provides basic understanding, but with no output schema or behavioral detail, the agent cannot know what the response will contain (e.g., metadata vs binary) or failure handling. This leaves a gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the sole parameter (fileId) with type and description. The description simply reinforces 'by file id' without adding new semantic details, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'one Strapi Media Library file by file id', clearly distinguishing it from sibling tools like strapi_list_media (list all files) and strapi_upload_media_from_url (upload). It fully states the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is given. The usage is implied by the name and description (fetch a single media file by ID vs listing via strapi_list_media), but there is no explicit mention of when to prefer this over other tools or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior, but it only says 'authenticated' without explaining which token is used or potential side effects. It doesn't mention response handling, rate limits, or error behavior. This is a significant transparency gap for a tool that can perform any HTTP method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, first stating core function and second giving usage guidance. Every word earns its place with no fluff, making it extremely concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a generic request tool with 5 parameters and no output schema or annotations, the description is too brief to fully inform an agent. It lacks details on response format, error cases, and how auth tokens are resolved—critical for an arbitrary request tool. The sibling tools help bound its use, but the description itself remains thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40% (path and useAdminToken have descriptions), leaving body, query, and method without schema docs. The description adds minimal parameter semantics—only that the request is to Strapi and can target admin endpoints. It doesn't clarify how to construct body vs query or the effect of method.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool makes an arbitrary authenticated request to Strapi, positioning it as a general-purpose endpoint client. It distinguishes itself from siblings by targeting custom endpoints and admin/content-manager routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this for custom endpoints and admin/content-manager endpoints, implying it is the fallback when specific CRUD tools don't apply. It doesn't explicitly exclude standard CRUD operations but the phrase 'custom' provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states 'Update' but does not explain whether the operation is a partial merge or a full replacement of metadata, whether it affects the binary file, or what side effects occur. This is a significant gap for a mutation tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clearly worded sentence that is front-loaded with the primary action and resource. Every word contributes to understanding the tool's purpose, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two well-documented parameters and a clear purpose, the description is adequate for basic invocation. However, it omits behavioral details such as partial update semantics and return value, which would be helpful in the absence of an output schema and annotations. The description is acceptable but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with examples, and the description reinforces that fields like name, alternativeText, and caption are metadata fields. Since schema coverage is 100%, the description adds minimal additional semantic value beyond providing relatable examples, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update'), the resource ('Strapi Media Library file metadata'), and gives concrete examples ('name, alternativeText, or caption'). This distinguishes it from sibling tools like strapi_update_entry, which updates content entries, and strapi_delete_media, which removes media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the phrase 'Media Library file metadata' and the examples, which suggests it is for metadata updates rather than content entry updates or file uploads. However, there is no explicit statement of when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It fails to explain whether the update is partial (PATCH) or full-replacement (PUT), what occurs if the entry does not exist, or how the Strapi version is determined. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the verb, resource, version-specific identifiers, and transport method without redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It omits update semantics (partial vs full replacement), error handling, and version assumptions. The schema richness is moderate but does not compensate for these essential gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes data, queryJson, and contentType well, and the description adds critical meaning to the documentIdOrId parameter by clarifying that it is documentId in Strapi 5 or id in Strapi 4. This compensates for the missing schema description on that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update a Strapi entry') and the resource, while explicitly distinguishing between Strapi 5 (documentId) and Strapi 4 (id). This unambiguously differentiates it from sibling tools like create_entry, get_entry, and delete_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is inferable from the name and description—it is used to update an existing Strapi entry—but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria such as 'only for existing entries' or version prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It fails to mention that this is a destructive, permanent operation, or any authentication/permission requirements, or what response to expect. Only version-specific ID semantics are added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with a clear subject and action. It is front-loaded with the verb and includes only necessary detail about versions and API.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core functionality and parameters are covered, but important operational gaps remain: no mention of permanence, permissions, errors, or return value. Given the absence of annotations and output schema, the description could be more complete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes contentType well. The description adds crucial meaning to documentIdOrId by explaining its role as documentId in Strapi 5 and id in Strapi 4, compensating for the missing schema description of that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete), resource (Strapi entry), and specifies the meaning of the ID for Strapi 5 vs 4. It is distinct from sibling tools like create/update/get/list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use this tool (to delete an entry) and provides context about versions, but it does not explicitly contrast with alternatives or mention conditions like irreversibility. Clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only adds a version-specific identifier detail, but does not state that this is a read-only operation, what happens if the entry is not found, or any error/edge-case behavior. The description is minimal and lacks transparency beyond the obvious 'get' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the core purpose without unnecessary fluff. It is well-structured and efficiently communicates the key information needed to understand the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool, the description is minimally adequate. It clarifies the identifier parameter, but it does not explain the return value, error behavior, or how to determine which Strapi version is in use. Given that there is no output schema and no annotations, the description could provide more context to fully support the agent, but the core purpose is still understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters with descriptions, but the documentIdOrId parameter is undocumented. The description adds meaning to this parameter by clarifying it should be a documentId in Strapi 5 or an id in Strapi 4, effectively compensating for the gap and providing valuable version-aware semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'one Strapi entry', and further specifies the identifier format based on Strapi version, which distinguishes it from list_entries and other sibling tools. The purpose is unambiguous even without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving a single entry by ID, distinguishing from list_entries which retrieves multiple. It also provides version-specific guidance on which identifier to use (documentId in Strapi 5, id in Strapi 4), but does not explicitly name alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It states the primary side effect (creating a media item via upload) and the key behavior of reading a local file from the machine. However, it does not mention permissions, failure modes, or the optional ability to attach media to an entry via ref/field/refId, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the verb 'Create,' and includes the crucial distinction 'local file path from this machine.' There is no filler or redundancy; every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no output schema, the description gives the essential purpose but lacks guidance on when to use optional relation parameters (ref, field, refId) or how the upload interacts with Strapi entries. It is sufficient for basic understanding but leaves room for more comprehensive autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, with all parameters except mimeType described in the schema. The description reinforces filePath's meaning ('local file path from this machine') but does not explain relationships among ref, field, refId, or filename defaulting. Since the schema does most of the parameter documentation, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create), the resource (Strapi Media Library item), and the specific method (uploading a local file path from this machine). This distinguishes it from the sibling tool strapi_upload_media_from_url, which uploads from a URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a local file path is available) by mentioning 'local file path from this machine,' which contrasts with URL-based uploads. However, it does not explicitly name alternative tools or list exclusions, leaving the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It accurately discloses the core behavior: downloading from a URL and uploading to /api/upload, implying network access and a write operation. However, it doesn't mention prerequisites like public accessibility, permission requirements, or side effects such as overwriting existing entries when ref/field/refId are used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 16-word sentence that front-loads the primary action and includes the mechanism. It contains no tautology or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a media upload tool with 6 parameters, no output schema, and no annotations, the description provides the essential 'what and how' but omits details about response format or failure modes. Optional relation parameters are reasonably explained in the schema, but the tool's overall behavior isn't fully specified. Still, an agent can likely select and invoke it correctly with the given information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 4 of 6 parameters (ref, field, refId, filename), and the description adds no additional parameter-level meaning beyond the schema. mimeType and url remain only schema-defined, but coverage is moderate at 67%, so the schema largely suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Create a Strapi Media Library item by downloading a URL and uploading it to /api/upload.' This distinguishes it from the sibling strapi_upload_media_from_file, which implies uploading from a local file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'downloading a URL' clearly indicates when to use this tool (when media is available via URL), but it doesn't explicitly exclude alternatives like strapi_upload_media_from_file or mention when-not scenarios. Sibling names provide context, but the description itself lacks direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![lapage-strapi-mcp MCP server](https://glama.ai/mcp/servers/zhuylanz/lapage-strapi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zhuylanz/lapage-strapi-mcp)

Score Badge

Copy to your README.md:

[![lapage-strapi-mcp MCP server](https://glama.ai/mcp/servers/zhuylanz/lapage-strapi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zhuylanz/lapage-strapi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhuylanz/lapage-strapi-mcp'

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