This MCP server lets you research, explore, and validate the weclapp REST API v2 — both offline via a bundled OpenAPI spec and live against a real tenant.
Knowledge & Exploration (no credentials required)
search_knowledge — Search across entities, fields, endpoints, and relationships by keyword or concept.
explain_entity — Get a full breakdown of an entity: fields, endpoints, references, projections, and read notes.
explain_endpoint — Look up details about a specific OpenAPI endpoint by path and HTTP method.
get_relationships — Discover cross-schema relationships for an entity, including optional inbound references.
plan_cross_entity_read — Generate an efficient read plan for fetching data across multiple entities using properties and includeReferencedEntities.
explain_filter_syntax — Learn weclapp v2 filter syntax, projection options, and includeReferencedEntities with examples.
compare_approaches — Compare a naive N+1 approach vs. the recommended efficient read plan for a given goal.
Live Probes (GET-only, requires API credentials)
execute_read_plan — Run a read plan against your live tenant to validate knowledge-layer recommendations.
probe_entity_sample — Fetch a bounded sample of a single entity from production for structure inspection.
probe_list_query — Run a bounded (capped page size) list query against production.
Analysis & Validation
analyze_response_structure — Analyze a JSON response: discover field paths, arrays, nulls, referenced entities, and types.
compare_to_schema — Diff a live API response against the OpenAPI schema fields for an entity.
explain_data_location — Find where a specific field lives in a response (top-level, nested, or referenced).
validate_read_plan — Verify that a read plan resolved the expected cross-schema data in a response.
validate_filter — Check filter shapes and field/operator names against the schema before using them in code or probes.
diagnose_api_error — Explain common weclapp API errors and suggest likely fixes.
check_field_presence — Confirm whether a field path exists in the OpenAPI spec and optionally in a live response payload.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@weclapp-api-knowledge-mcp Explain the article entity and its relationships."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A standalone Model Context Protocol server for researching the weclapp REST API v2. Use it from Cursor, Claude Desktop, or any MCP-compatible client to explore entities, endpoints, relationships, and filter syntax — and optionally validate read patterns against your own tenant.
Not affiliated with weclapp. This is an independent open-source project maintained by the community.
It combines:
Offline API knowledge from data/openapi_v2.json: entities, endpoints, fields, cross-schema relationships, filter syntax, and efficient read plans.
Bounded live probes against one weclapp tenant: read-only GET requests that validate plans, inspect real response structure, and diagnose API errors.
This is not a CRUD wrapper. Its main job is to answer: how should I communicate with the weclapp API, where does data live, and how do I fetch cross-schema data efficiently?
Knowledge tools work without credentials. Live probe tools require a read-only weclapp API token.
Related MCP server: OpenAPI Schema Explorer
Knowledge tools:
search_knowledge
explain_entity
explain_endpoint
get_relationships
plan_cross_entity_read
explain_filter_syntax
compare_approaches
Live probe tools (GET-only and bounded):
execute_read_plan
probe_entity_sample
probe_list_query
Analysis and validation tools:
analyze_response_structure
compare_to_schema
validate_read_plan
validate_filter
diagnose_api_error
check_field_presence
See docs/TOOLS.md for parameter details and usage notes.
Python 3.11+
uv (recommended) or pip
Optional: Docker, for SSE transport via mcp-remote
Optional: weclapp API credentials for live probes
git clone https://github.com/serenmind/weclapp-api-knowledgebase-mcp.git
cd weclapp-api-knowledgebase-mcp
uv syncLive probe tools need a read-only weclapp token:
cp .env.example .env
# Edit .env and set WECLAPP_BASE_URL and WECLAPP_API_KEYuv run pytestRecommended — stdio with Cursor
Add to your Cursor MCP settings (.cursor/mcp.json or Cursor Settings → MCP):
{
"mcpServers": {
"weclapp-api-knowledge": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/weclapp-api-knowledgebase-mcp",
"run",
"weclapp-api-knowledge-mcp"
],
"env": {
"MCP_TRANSPORT": "stdio"
}
}
}
}Add WECLAPP_BASE_URL and WECLAPP_API_KEY to env if you want live probes.
Alternative — Docker + SSE
cp .env.example .env
docker compose up --buildThen connect via mcp-remote:
{
"mcpServers": {
"weclapp-api-knowledge": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"http://localhost:8080/sse",
"--transport",
"sse-first"
]
}
}
}More client examples: docs/CLIENT_SETUP.md.
Variable | Required | Default | Description |
| For live probes | — | Tenant API base, e.g. |
| For live probes | — | Read-only API token |
| No |
| Auth header name |
| No |
| Path to OpenAPI spec |
| No |
|
|
| No |
| SSE bind host |
| No |
| SSE bind port |
| No |
| Max rows for list probes |
| No |
| HTTP timeout for live probes |
No write tools are exposed.
Live probes only issue GET requests.
List probes cap pageSize with WECLAPP_MAX_PAGE_SIZE (default: 10).
Credentials are read from environment only.
The bundled OpenAPI file can be refreshed when weclapp updates v2.
Replace data/openapi_v2.json with an updated weclapp v2 OpenAPI export, then restart the server. The MCP server reads and caches the spec directly at runtime.
uv sync
uv run pytest
uv run ruff check src tests
MCP_TRANSPORT=stdio uv run weclapp-api-knowledge-mcpMIT — see LICENSE.
Analyze live or sample JSON: paths, arrays, nulls, referencedEntities, and types.
| Name | Required | Description | Default |
|---|---|---|---|
| response | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states 'analyze' implying a read-only operation, but it does not explicitly confirm no side effects, authentication needs, or rate limits. The behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is to the point and front-loaded. No words are wasted, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool's complexity (analyzing JSON structure) is not fully covered. The description omits return behavior, edge cases, and scope, making it insufficient for confident agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It indicates the 'response' parameter expects JSON ('live or sample JSON'), but it does not elaborate on required structure, keys, or constraints. The added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Analyze' and the resource 'live or sample JSON', listing specific aspects like paths, arrays, nulls, referencedEntities, and types. This gives a good sense of what the tool does but does not explicitly differentiate it from sibling tools such as check_field_presence or compare_to_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description mentions analyzing live or sample JSON but fails to specify prerequisites, context, or exclusions, leaving the agent without decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a field path exists in OpenAPI and optionally in a live payload.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| field_path | Yes | ||
| response | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states it checks existence but doesn't explain side effects, auth needs, or behavior when 'response' is provided vs. null. Assumes read-only but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. However, it could be expanded to include parameter details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (one optional) and an output schema, the description lacks explanation of return values, parameter roles, and how this tool fits among many similar sibling tools. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains 'field_path' implicitly but leaves 'entity' and 'response' unexplained. No details on required format or optional behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks field path existence in OpenAPI and optionally in live payload, with a specific verb and resource. It distinguishes from siblings like 'analyze_response_structure' by focusing on presence rather than structure, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'validate_filter' or 'explain_endpoint'. Lacks context of intended usage or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare naive N+1 API research with the recommended efficient read plan.
| Name | Required | Description | Default |
|---|---|---|---|
| root_entity | Yes | ||
| goal | Yes | ||
| needs | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any behavioral details beyond the core action. With no annotations provided, the agent cannot infer whether this is a read-only operation, requires authentication, or has side effects. The output schema exists but is not described, so the agent has no insight into what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of necessary detail. It front-loads the purpose but omits important information about parameters and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters, zero schema descriptions, and lack of annotations, the description is insufficient for an agent to confidently use this tool. The existence of an output schema is noted but not leveraged in the description. The description needs to cover parameter meanings and typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for any of the three parameters (root_entity, goal, needs). The agent has no semantic understanding of what to provide for each parameter, making correct invocation difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: comparing two research approaches (naive N+1 vs efficient read plan). It distinguishes from siblings like plan_cross_entity_read and validate_read_plan which focus on planning or validation, not comparison. However, it could be more precise about the output or what 'compare' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical scenarios, or situations to avoid. Sibling tools provide related functionalities but no differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a live payload with the OpenAPI schema fields for an entity.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| response | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It fails to mention what happens with mismatches, return format, or any side effects. The description is too brief to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure (e.g., no bullet points or sections). It is front-loaded with the action but too sparse for a tool with two parameters and an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description could rely on it for return values, but it fails to provide adequate context for the input parameters. The tool is incomplete for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the 'entity' and 'response' parameters beyond their names, leaving the agent to guess their meaning and required format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares a live payload to OpenAPI schema fields for an entity, providing a specific verb and resource. It is distinguishable from sibling tools, though it could be more explicit about the comparison outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like validate_filter or validate_read_plan. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain common weclapp API errors and likely fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| error | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavior. It only states that it explains errors and fixes, omitting details like return format, limitations (e.g., only common errors), or how the error parameter is processed. The input schema accepts both string and object, but the description does not clarify usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but lacks structure and detail. While brevity can be a virtue, it omits critical information and front-loads only the core purpose, leaving the agent under-informed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description does not need to detail return values. However, the lack of annotation coverage and missing parameter guidance means the definition is incomplete for a diagnostic tool. It fails to provide enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'error' has no description in the schema (0% coverage) and the tool description adds no meaning. It does not explain acceptable formats, examples, or what constitutes a valid error input. This severely hinders effective use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Explain common weclapp API errors and likely fixes.' The verb is specific (explain), the resource is well-defined (common weclapp API errors), and it distinguishes from sibling tools like analyze_response_structure and check_field_presence, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Siblings like explore_entity_sample or validate_filter could also be relevant in different scenarios, but the description does not mention any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a GET-only read plan against production to validate a knowledge-layer recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it is GET-only and executes against production, implying read-only and potential production impact. However, it lacks details on side effects, authentication requirements, rate limits, or any behavioral nuances. With no annotations provided, the description carries full burden and only minimally discloses behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise. However, it lacks structure such as sections for input, output, or examples. While no waste, it is too terse and omits important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested object parameter) and the presence of an output schema, the description fails to explain what a 'read plan' is, what the output represents, or how this tool fits into the broader workflow. It is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the single 'plan' parameter's structure, contents, or format. The input schema only defines it as an object with additionalProperties. The description adds no semantic value beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool executes a GET-only read plan to validate a knowledge-layer recommendation. It uses a specific verb and resource, but the term 'knowledge-layer recommendation' is vague, and it does not distinguish from sibling tools like 'validate_read_plan'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'validate_read_plan' or 'plan_cross_entity_read'. There is no mention of prerequisites, when-not to use, or explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find where a field appears in a response and whether it is nested or referenced.
| Name | Required | Description | Default |
|---|---|---|---|
| response | Yes | ||
| field_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear full transparency burden. It only says 'whether it is nested or referenced' but does not disclose how this is determined, what output format is used, or any limitations (e.g., handling of multiple occurrences).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but omits necessary detail for effective use. It would benefit from additional sentences explaining output and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two required parameters, nested objects, and an output schema, the description is incomplete. It does not mention what output to expect (e.g., a path string or list of paths) or how the tool relates to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should compensate. But it adds no meaning beyond parameter names. 'response' and 'field_name' are obvious from names; the description does not explain expected format, constraints, or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'find' and the resource 'field in a response', and specifies two aspects: location (where it appears) and structure (nested or referenced). This distinguishes it from sibling tools like 'check_field_presence' which would only check existence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'analyze_response_structure' or 'check_field_presence'. There are no when/why/exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain one OpenAPI endpoint by path and method.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| method | No | GET |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure but only states the action without any details on side effects, required permissions, output format, or constraints. It offers minimal transparency beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundancy, perfectly concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no annotations, output schema exists), the description is minimally viable but lacks context about scope, source of the API spec, or any associated behavior. It meets the bare minimum but does not exceed it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not compensate by explaining the meaning, format, or expected values of 'path' and 'method'. It merely repeats the parameter names, adding no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'explain' and the resource 'OpenAPI endpoint', and specifies the two inputs (path and method). It distinguishes from sibling tools like 'analyze_response_structure' or 'explain_entity' by focusing on endpoints uniquely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no exclusions, no prerequisites, and no context about the intended usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain one weclapp entity: fields, endpoints, references, projections, and read notes.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It describes the output scope but does not explicitly state it is read-only or safe. Adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, no repetition, every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema likely detailing response structure, the description covers key aspects. Minor improvement possible by explicitly noting it is a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the entity parameter. Description adds minimal meaning by stating it explains a 'weclapp entity', but lacks examples or format details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Explain one weclapp entity' and lists specific aspects (fields, endpoints, references, projections, read notes), distinguishing it from siblings like explain_endpoint which focus on single aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as the tool for comprehensive entity explanation, but lacks explicit guidance on when to prefer it over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain weclapp v2 filters, projection, includeReferencedEntities, and examples.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention return type, safety, side effects, or permissions. The description is insufficient for an agent to understand the tool's action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with the key action first. However, it includes a typo ('weclapp' instead of 'weclapp') and omits parameter details, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the optional parameter and presence of an output schema, the description could be more complete. It does not explain what the tool returns or how to use the output, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'entity' parameter at all. With 0% schema coverage, the description should compensate, but it fails to explain how the parameter affects the output or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool explains weclapp v2 filters, projection, includeReferencedEntities, and examples. This differentiates it from sibling tools like explain_entity or explain_endpoint by focusing on filter syntax.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as validate_filter or explain_entity. The description lacks context about prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return cross-schema relationships discovered from x-weclapp.entity references.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| include_inbound | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full responsibility for behavioral disclosure. It only states the tool 'Return' data, implying a read operation, but fails to mention any traits like idempotency, required permissions, rate limits, or whether it is safe to use repeatedly. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately concise for a simple tool, though it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not hint at the structure or format of the returned relationships. For a tool that returns 'cross-schema relationships', more context is needed (e.g., what relationship attributes are included, pagination, or filtering). The 0% schema coverage for parameters also contributes to incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description omits any explanation of the two parameters ('entity' and 'include_inbound'). It does not clarify what 'entity' represents or how 'include_inbound' affects results. Without this, an AI agent cannot correctly invoke the tool with intended values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns cross-schema relationships using a specific verb ('Return') and resource ('cross-schema relationships'), and identifies the source ('x-weclapp.entity references'). While the term 'x-weclapp.entity references' may be cryptic to new users, it is likely domain-specific and differentiates from sibling tools like 'explain_entity' or 'probe_entity_sample'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, scenarios, or exclusions, making it difficult for an AI agent to decide between 'get_relationships' and siblings like 'check_field_presence' or 'explain_data_location'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan an efficient read using properties and includeReferencedEntities where possible.
| Name | Required | Description | Default |
|---|---|---|---|
| root_entity | Yes | ||
| goal | Yes | ||
| root_id | No | ||
| needs | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'plan' without disclosing side effects, authentication needs, rate limits, or what the plan output entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks informative details; front-loads the action but under-specifies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no descriptions, no annotations, and an output schema not elaborated, the description fails to provide sufficient context for an AI agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides no explanation of the four parameters (root_entity, goal, root_id, needs) despite 0% schema description coverage. Terms like 'properties' and 'includeReferencedEntities' are not mapped to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool plans an efficient read using properties and includeReferencedEntities, which is clear but does not explicitly distinguish it from sibling tools like execute_read_plan or validate_read_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no mention of prerequisites, exclusions, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one bounded sample from production for structure research and validation.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| entity_id | No | ||
| filters | No | ||
| properties | No | ||
| include_referenced_entities | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions fetching from production and a 'bounded sample,' but fails to explain what 'bounded' means, potential side effects, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single direct sentence with no superfluous text. It is concise, though it could be restructured to front-load the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no annotations, and a schema coverage of 0%, the description is far from complete. An output schema exists but is not referenced. The description fails to provide sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. However, it provides no information about the five parameters (entity, entity_id, filters, properties, include_referenced_entities), leaving the agent without guidance on their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetch' and the resource 'one bounded sample' with a specific purpose 'structure research and validation.' It is distinct from sibling tools like 'probe_list_query' which implies fetching multiple items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives such as 'probe_list_query' or 'explain_entity.' The description implies usage for sampling but offers no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe a bounded list query against production. GET-only, capped page size.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| filters | No | ||
| properties | No | ||
| page_size | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is read-only ('GET-only') and imposes a page size cap, which are key behavioral traits. However, with no annotations, it fails to mention other important behaviors like error handling, rate limits, or whether the query can return all results or just a sample. This leaves gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but it sacrifices clarity. While there is no wasted text, it omits crucial details that would fit within a few more phrases. The structure is front-loaded with key info but overall too terse for a tool with 4 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention what the output contains or how pagination works beyond a capped page size. It also lacks information on error conditions, data freshness, or relationship to other tools. This incompleteness hampers autonomous selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description bears full responsibility for explaining parameters, but it only vaguely implies that 'entity' is the target and 'page_size' is capped. It offers no explanation for 'filters' or 'properties', requiring the agent to rely on parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's action ('Probe a bounded list query against production') and includes key distinguishing traits ('GET-only, capped page size'). This differentiates it from sibling tools like probe_entity_sample or execute_read_plan, which focus on different aspects of reading data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 its siblings. There are no explicit instructions on prerequisites, context, or alternatives such as probe_entity_sample or plan_cross_entity_read. The agent must infer usage solely from the sparse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search weclapp API knowledge across entities, fields, endpoints, and relationships.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the search scope but does not reveal whether the operation is read-only, idempotent, or whether it requires authentication or has rate limits. The output format or pagination behavior is not hinted at despite the 'limit' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys the tool's action and scope. Every word contributes meaning, with no redundancy or filler. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (one required), no annotations, and an output schema exists, the description is incomplete. It does not explain how results are returned, whether there are advanced search options, or how the tool handles ambiguous queries. The absence of usage examples or behavioral notes makes it insufficient for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate but adds minimal meaning. It does not clarify what constitutes a valid 'query' (e.g., free text, field-specific patterns) or the effect of 'limit' (maximum results, default behavior). The description simply restates the tool's purpose without explaining parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Search weclapp API knowledge') and scope ('across entities, fields, endpoints, and relationships'). It distinguishes itself from sibling tools like 'explain_entity' and 'explain_endpoint' by being a general search rather than a focused explanation. However, it does not explicitly differentiate from 'get_relationships' or 'explain_data_location'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternative sibling tools. It does not specify scenarios where this broad search is preferred over more specialized tools like 'explain_entity' or 'plan_cross_entity_read'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate filter shape and field/operator names before probing or coding.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| filters | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It says 'validate', which implies a read-only check, but does not state whether it returns a boolean, throws errors, or has side effects. The behavioral nature is minimally described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but at the cost of completeness. It front-loads the purpose but omits parameter details and usage context. It is adequate but not efficient in conveying all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (2 required params, no output schema shown) and sibling tools like explain_filter_syntax and probe_entity_sample, the description is incomplete. It does not explain the return value, when to use this vs. explain_filter_syntax, or what 'valid' means. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (entity, filters) with 0% schema description coverage. The description does not mention any parameter, leaving the agent to guess that entity is likely the resource type and filters is the filter object to validate. No additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: validate filter shape and field/operator names. It distinguishes from siblings like validate_read_plan and explain_filter_syntax by focusing on filter syntax validation before probing or coding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before probing or coding' implies a usage context, but there is no explicit guidance on when not to use this tool or alternatives. For example, it could mention that this is a preliminary step to ensure filters are valid before using explore_filter or probe_entity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate that a read plan produced the expected cross-schema resolution.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | ||
| response | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose if the tool is read-only, whether it has side effects, or what happens on validation failure. It only states the operation without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but insufficient for a tool with two complex object inputs. It does not front-load key details or structure information effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the parameters and the existence of an output schema, the description should at least hint at input semantics or validation criteria. It is completely lacking, leaving the tool poorly specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'plan' and 'response' parameters. Their types are generic objects with additionalProperties, leaving the agent without guidance on expected structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a read plan for expected cross-schema resolution, distinguishing it from siblings like execute_read_plan and compare_to_schema. However, 'cross-schema resolution' is somewhat jargon-y and may not be immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 compare_to_schema or analyze_response_structure. The description lacks any context for triggering or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0analyze_response_structurecheck_field_presencecompare_approachescompare_to_schemadiagnose_api_errorexecute_read_planexplain_data_locationexplain_endpointexplain_entityexplain_filter_syntaxget_relationshipsplan_cross_entity_readprobe_entity_sampleprobe_list_querysearch_knowledgevalidate_filtervalidate_read_planEach tool has a clearly distinct purpose, covering analysis, validation, querying, and explanation. There is minimal overlap, e.g., execute_read_plan vs validate_read_plan are differentiated by execution vs validation.
All tool names follow a verb_noun pattern in snake_case (e.g., analyze_response_structure, validate_filter). The naming is consistent and predictable across the entire set.
With 17 tools, the server covers a comprehensive range of API knowledge tasks without being excessive. Each tool serves a specific need in exploring and validating the weclapp API.
The tool surface covers major operations: analysis, schema validation, query planning, relationship discovery, and error diagnosis. It lacks some bulk or batch operations, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides access to Testiny projects, test cases and test runs
Read-only MCP server over the APIs.io catalog — discover APIs, providers, tags & artifacts.
MCP server for innovationlab documentation, generated by doc2mcp.
A basic MCP server to operate on the Postman API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/serenmind/weclapp-api-knowledgebase-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
