Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server defines 10 tools with consistent naming (semantic_calculator_* prefix) and mostly complete schemas. However, descriptions are generic and lack LLM-facing guidance on WHEN to use each tool. Parameter descriptions exist but are minimal (e.g., 'First vector', 'Second vector'). No output schemas are documented, LLMs cannot plan what fields to expect. Error handling is absent from tool definitions. Tool names use 'semantic_calculator_' prefix (verbose but consistent), though the verbs are weak (text_to_vector is acceptable, but parse_emojikey_string lacks motivation). Overall, tools are functional but not optimized for agent reasoning. Average per-tool score: 52.
Calculate helical components from magnitude and phase angle. This implements the 'Clock algorithm' concept from the MIT paper on helical representations in LLMs.
Tool descriptions are minimal or generic (10-50 chars). Examples: 'Convert text to a vector embedding.' (38 chars), 'Calculate the cosine similarity between two vectors.' (53 chars). No guidance on WHEN to use each tool vs similar ones, no prerequisites, no context. LLMs cannot differentiate among distance metrics without better motivation.
Document output schema for each tool in the server. For example, semantic_calculator_text_to_vector should declare it returns {type: 'object', properties: {vector: {type: 'array', items: {type: 'number'}, description: 'Embedding vector (768 dims)'}}}. This lets LLMs chain calls and predict downstream requirements.
Expand tool descriptions to 80 - 150 chars and answer: WHAT does it do? WHEN to use it vs similar tools (e.g., 'Use cosine_similarity for comparing semantic meaning; use euclidean_distance for geometric proximity'). Example: 'Convert text to a 768-dimensional embedding vector using sentence-transformers. Use before similarity or distance calculations.'
Add constraint details to parameter descriptions. For 'vector' params, specify expected dimensionality (e.g., '768-element numeric array'). For 'method' params, clarify choice: 't-SNE: better for visualization and cluster separation; UMAP: faster, preserves global structure'.
Shorten tool names by dropping the 'semantic_calculator_' prefix. Use: text_to_vector, emoji_to_vector, cosine_similarity, etc. The server registration already scopes these.
Add error handling hints to tool descriptions. Example: 'Will fail if vectors have mismatched dimensions. Use text_to_vector and emoji_to_vector to ensure compatible embeddings.' This guides LLMs on preconditions.
For 'dimensions' parameter, add enum constraint: [2, 3] instead of generic 'integer'. For 'periods' parameter, document the expected range (e.g., 'positive floats, commonly [2, 5, 10, 100]') and add a minItems constraint.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 9 points across a rubric change (v1 → v2)
49/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
49
<=2025-11-25
v2
2026-03-09
F
40
-
v1
source verified
58/100
Calculate the Manhattan distance between two vectors.
Parameter descriptions are terse (e.g., 'First vector', 'Second vector', 'The text to convert'). No constraints, format specs, or usage guidance. Missing: expected dimensionality, value ranges, when vectors are valid, what errors may occur.
No error handling or recovery guidance in tool definitions. If a user passes mismatched vector dimensions or invalid emoji, LLM has no hint what to do next. No error taxonomy or examples.
Tool names use verbose prefix 'semantic_calculator_' on every tool. While consistent, this adds 20+ chars per name, reducing naming clarity. Better: 'text_to_vector', 'emoji_to_vector', 'cosine_similarity' (LLM context still scoped by server).
Parameter 'method' in dimensionality_reduction and vectors_to_3d_coordinates accepts 't-SNE' or 'UMAP' but is documented only as 'Reduction method: t-SNE or UMAP'. No description of when to pick each, performance tradeoffs, or effect on output quality.
Parameters 'dimensions' (2 or 3) and 'periods' (list of floats) lack validation guidance. What if an LLM passes dimensions=5 or periods=[]? No bounds, no enum, no error example provided.
Define the emojikey string format in parse_emojikey_string description. Currently it just says 'The emojikey string to parse', LLMs don't know the syntax. Document format: 'A space-separated string of emojis, e.g., "😀 😂 🤔"' or the actual format used.
Add an 'examples' section to complex tools like calculate_helical_components. Show: input magnitude=0.8, phase_angle=45, periods=[2,5,10] produces [output structure]. LLMs use examples to infer expected ranges and shapes.