Loading ToolBench
Center of Excellence Reconnaissance — remote MCP server serving the corpus (domains), method (procedure prompts), and genericized HTML template. Deployed on Cloudflare Workers with Python STDIO adapter.
CoER Nucleus exposes 10 read-only tools with consistent naming (verb_noun pattern: list_, get_, draft_) and clear descriptions (avg ~150 chars). All tools have input schemas defined via Zod in TypeScript. However, parameter descriptions are sparse or missing in several tools (e.g., 'contribution' in draft_contribution lacks field-level guidance), and output schemas are not formally documented. Error handling is minimal, most tools return JSON with error fields rather than actionable recovery guidance. The server is stateless and HTTP-based (Cloudflare Workers), meeting current protocol standards, but lacks tool annotations (readOnlyHint, idempotentHint) and structured error classification.
Validate a contribution (domain | enrichment | entity | method | correction) and return a normalized artifact plus a human-addressed note on how to submit it via PR or issue. Read-only: this writes nothing. Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
The JSON schema for contributions, or a single type's branch when `type` is given. Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
Get the full CoER reconnaissance dashboard (all 12 panels) for a domain slug. Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
The fuzzy->structured cascade prompts that fill a new landscape from a raw interest. Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
The canonical CoER method: 6 sequential steps + 4 standing sourcing while-loops. Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
Identity, capabilities, and data-handling posture of this server, so a client can verify trust against public source rather than the operator. Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
draft_contribution parameter 'contribution' lacks field-level schema documentation. The description states it is 'A contribution object with type, and type-specific fields' but does not enumerate which fields are required for each type (domain, enrichment, entity, method, correction) or their formats.
No output schemas documented for any tool. LLMs cannot infer the structure of returned data (e.g., what fields does a domain object contain? What is the structure of contribution_schema?). This forces agents to guess or make exploratory calls.
Error handling is minimal and non-actionable. get_domain returns {error: '...', available: [...]} but does not guide the LLM on next steps. No error classification (retryable vs user-fixable vs fatal) or recovery suggestions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2026-07-28+ | v2 |
The genericized, agent-retrieval-friendly HTML version of the CoER template (panels mapped to schema fields and method steps). Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
The workflow for contributing context, methods, or discovered domains back to the CoER atlas — addressed to a human (or an agent acting with its operator's consent), not an instruction to execute. Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
List the granular back-contribution types and what each is for. Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
List every CoER reconnaissance landscape in the atlas (slug, name, completeness). Source: https://github.com/pastarita/coer-nucleus (MIT, read-only).
Tool annotations missing. All 10 tools are read-only and idempotent, but neither readOnlyHint nor idempotentHint is declared in tool metadata. This forces LLMs to infer safety from descriptions, increasing hallucination risk.
get_contribution_schema 'type' parameter enum is well-defined, but the description does not explain what each type represents or when to use each. LLMs must cross-reference list_contribution_types to understand the distinction.