A multi-service MCP server ecosystem supporting customer request management, service locator, and agent-based automation. Includes CAP-based MCP servers for customer requests and service locator, plus a Python agent that consumes MCP tools via HTTP.
This server exposes 4 tools but provides almost no verifiable schema definitions, parameter descriptions, or output documentation in the source code. Tool names are generic and lack action verbs. The code snippet shows only a Python loader function (get_mcp_tools) with no visible tool registration, schema, or parameter metadata. CAP applications (customer_request_mcp_tools, service_locator_mcp_tools) are referenced by package.json but their actual MCP tool definitions are not visible in the provided source. load_skill_resources is mentioned but not defined. Without access to actual tool schemas, parameter types, descriptions, and output structures, this server cannot be scored higher. The architecture suggests tools are dynamically loaded from external MCP servers or mock data, but the definitions themselves are not present in the repository snapshot.
MCP tools exposed by the Altura Customer Service CAP application for managing customer requests via OData
Loader function that retrieves MCP tools from configured external MCP servers via HTTP or from mock data for testing. Supports OAuth2 client credentials flow for authentication.
Tool that loads skill resources for the agent, enabling dynamic skill loading and execution
MCP tools exposed by the Service Locator CAP application for querying service center locations via OData
No input schemas visible for any tool. Cannot verify parameter types, constraints, or required fields.
Tool names lack action verbs. 'customer_request_mcp_tools' and 'service_locator_mcp_tools' are noun-based and do not convey what action the LLM should expect. Should be verb_noun like 'get_customer_requests', 'create_customer_request', 'search_service_locations'.
Descriptions are generic and under 50 characters. 'MCP tools exposed by the Altura Customer Service CAP application' does not explain WHAT the tool does, WHEN to use it, or what it returns. LLMs cannot determine tool selection from these descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 28 | 2026-07-28+ | v2 |
Tool definitions are inferred from package.json references, not explicitly visible in source code. Actual MCP tool registration, schemas, and parameter metadata are not provided.
No output schemas documented. Unclear what fields each tool returns, what types they are, or how downstream tools should consume the results. Breaks tool chaining and forces LLMs to guess.