santismm-knowledge

Official

by santismm

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v0.4.1
Disambiguation3/5
The list_/get_ pairs for each content type are clearly separated, and the calculate_* tools are unambiguous. The main overlap is among search, search_all, and search_articles: search_all intentionally supersets the others, and while the descriptions clarify the scopes, an agent could still hesitate over which search to call first.
Naming Consistency4/5
The tool set strongly follows a verb_noun snake_case pattern with consistent list_/, get_/, search_/, and calculate_/ prefixes. Minor deviations such as bare search, search_all, get_related, and the singular get_homeric_place versus plural list_homeric_places prevent a perfect score.
Tool Count4/5
Thirty tools is high for a typical MCP server, but this one explicitly spans multiple surfaces: core knowledge, articles, labs, the Homeric Atlas, and the claim registry. Each surface has dedicated list/get tools plus specialized search and calculation tools, so the count feels purposeful rather than bloated.
Completeness5/5
The tool set provides full read-side coverage: discovery via get_overview and list_* tools, retrieval via get_* tools, cross-surface discovery via search and search_all, graph traversal via get_related, and specialized calculators. For a read-only knowledge server, create/update/delete tools are not expected, and every described surface is reachable.
Average 4.4/5 across 30 of 30 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 47 commits in the last 12 weeks
- Last stable release on September 2, 2026
- 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.
Tools from this server were used 22 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; the description adds valuable behavioral context: language-insensitive matching, accent ignoring, relevance scores, and matched fields per hit. No contradictions with annotations.
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?
Three tightly worded sentences with the core action first, followed by language behavior, hit contents, and usage guidance. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what is searched, how to phrase queries, what results contain, and how to follow up. The only gap is not addressing the relationship to the sibling 'search_all', which could slightly confuse tool selection.
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%, so parameters are well documented. The description adds some query-level nuance ('Matches every language and ignores accents') but does not enrich limit, locale, or domains beyond the schema.
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?
States a clear verb and resource: 'Ranked keyword search across the whole corpus' with explicit domain coverage. It distinguishes itself from get_* tools but does not differentiate from the sibling 'search_all', which also implies whole-corpus search.
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?
Explicitly instructs when to use: 'Use this before any `get_*` tool whenever you have a question rather than an identifier.' However, it does not mention when not to use it or alternatives like search_all or search_articles.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds no behavioral caveats such as pagination, auth requirements, or input resolution behavior—only content details. It does not contradict the annotations.
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?
Two sentences with no filler. The operation is front-loaded, followed by the returned contents and then the precise use case. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple retrieval tool with a single required parameter, full schema coverage, and an output schema. The description conveys both the trigger condition and the return contents; nothing needed to call it correctly is missing.
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%, with slug and locale already documented in the input schema. The description only repeats the idea of fetching 'by slug' and does not add extra meaning about slug format or locale behavior, so the schema carries the parameter burden.
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 opens with a specific verb and resource: 'Get one episode by slug'. It then enumerates the exact contents returned (passage, narrative, competing theories with proponents and sources, confidence rubric, FAQs), which clearly distinguishes it from siblings like list_homeric_episodes and get_homeric_place.
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?
It gives an explicit use case: 'Use this when the question is where an episode took place and who argued for it.' This tells an agent when to reach for it, though it does not explicitly mention alternatives or cases where list_homeric_episodes would be more appropriate, so it stops short of full routing guidance.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the included content sections, which is marginally useful, but does not reveal other behavioral traits such as not-found handling, locale defaults, or any rate limits. With annotations present, this meets the baseline.
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?
Two short sentences with zero fluff: the first states the purpose and return contents, the second gives the usage trigger. Information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with annotations, a complete input schema, and an output schema, the description provides all necessary selection and invocation context. It even routes the user to the correct preceding tools (search/list_patterns), making the definition fully adequate.
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%, so both slug and locale are already documented in the input schema. The description only mentions 'by slug' and adds no new parameter-level meaning, keeping the score at the baseline for full 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 states a specific verb ('Get'), resource ('Enterprise AI pattern'), and access method ('by slug'), and enumerates the content included (problem, solution, KPIs, failure modes, lessons). This clearly differentiates it from sibling list/search tools like list_patterns and search.
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?
It explicitly instructs to use this tool after search or list_patterns has returned a slug, providing a clear invocation context. It does not name alternative get_* tools for other resource types, but the guidance is sufficient for the primary workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavioral context beyond that: the result is an average-based estimate rather than a queueing simulation, which materially affects how an agent should interpret the output. No contradiction with annotations exists.
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?
Two sentences with zero waste: the first front-loads the complete set of computed outputs, and the second delivers the usage context and the critical limitation. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter calculation tool with 100% schema coverage, an output schema, and annotations covering the safety profile, the description is nearly complete. It covers purpose, timing, and the key interpretive caveat. The only minor gap is not pointing to a sibling tool for the queueing-simulation case it explicitly disclaims.
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%, so the schema fully documents all 11 parameters including units, ranges, and meaning. The description adds no parameter-level details beyond naming the computed outputs, so the baseline of 3 applies — 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 uses a specific verb (Calculate) with a clear resource (human supervision capacity) and enumerates five concrete outputs: workload, required FTE, headroom/backlog, monthly labour cost, and sustainable case volume. This output list makes it easy to distinguish from sibling calculation tools like calculate_agent_economics and calculate_evaluation_sample_size, which cover different domains.
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 states when to use the tool ('before production rollout') and what question it answers ('whether the stated human-oversight model is operationally credible'). It also provides a meaningful exclusion caveat ('not a queueing simulation'), though it does not name specific alternative tools for cases where a queueing simulation is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explaining that it returns one-hop neighbours in both directions and includes relationship types, which is not stated in the annotations or schema.
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?
Two sentences accomplish a lot: they state the operation, the input, the output shape with directions, and the recommended invocation context. There is no wasted wording, and the key behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, annotations covering safety, and the description explaining usage and return semantics, the definition is largely complete. It does not mention pagination, recursion depth, or how locale affects the results, but these are not critical given the existing schema and read-only nature.
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 67%, and the description does not add much parameter-specific detail beyond what the schema provides. It clarifies the conceptual role of slug/domain as a 'unit' and mentions locale defaults elsewhere, but it does not describe domain enum meanings or the exact expected relationship between parameters.
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 a specific operation—traversing the knowledge graph from a given unit to its neighbours—and specifies what is returned: outgoing and incoming units, each with a relationship type. This clearly distinguishes it from sibling get_* and list_* tools that fetch single units or enumerate lists.
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 gives clear when-to-use guidance: use it after a `get_*` call to widen an answer with adjacent units. It does not explicitly say when not to use it or name alternatives, but the contextual instruction is sufficient for typical agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral detail beyond that: results are 'ranked', matching is 'accent-insensitive', and search spans 'titles, summaries, topics and bodies'. This meaningfully informs expectations without contradicting the annotations.
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 with no filler. The first sentence front-loads the core function and scope, and the second provides actionable usage guidance. Every phrase contributes to correct selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool, the description covers what is searched, the result flavor (ranked, accent-insensitive), and how to proceed. The output schema exists, so return-value documentation is not required in the description. Minor room remains for explicitly contrasting with broader search tools, but nothing essential is missing.
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%, so query, limit, and locale are already documented in the input schema. The description adds context about ranking and accent-insensitivity but does not need to restate parameter meanings; the baseline 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 identifies a specific verb ('search'), a well-defined resource ('first-party essays'), and the scope ('every first-party essay, including titles, summaries, topics and bodies'). It clearly distinguishes this from sibling tools like list_articles (which lists rather than searches) and get_article (which retrieves a complete essay).
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 gives a direct usage trigger ('Use this when you need long-form analysis about a topic') and a follow-up action ('follow with get_article for the complete essay'). It does not explicitly describe when to prefer search_all or search, but the essay-specific context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context by explaining the dual outputs and warning against misinterpreting zero failures as proof of zero risk. This goes beyond what annotations alone communicate.
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 three sentences with no filler. It front-loads the core purpose, gives usage context, and adds a valuable statistical caution. Every sentence contributes to correct tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema, complete input schema, and strong annotations, the description provides all necessary context: what the tool computes, when to reach for it, and a critical interpretation warning. Nothing material is missing for an agent to invoke it correctly.
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%, so the schema fully documents all five parameters. The description mentions 'margin' and 'failure rate' conceptually and explains why the parameters matter, but it does not add formatting, units, or relationship details beyond the schema. Baseline 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 states a specific action ('Calculate two different samples') and identifies exactly what is calculated: sample size to detect at least one failure and sample size to estimate its rate. It clearly distinguishes this from the surrounding retrieval tools by focusing on statistical calculation for evaluation sample sizing.
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 gives explicit guidance: 'Use this when a user asks how many tests are enough.' It also includes a non-obvious interpretive caution about zero observed failures. However, it does not name alternative tools or explicitly state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond those annotations by specifying the shape of the returned content, including the clean Markdown-like body, licence context, and canonical URL.
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?
Two sentences that are fully informative and front-loaded. The first sentence states what the tool returns; the second gives the prerequisite workflow. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with an output schema and strong annotations, the description is complete. It tells the agent what to call before this tool, what the slug is, and what the result contains.
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 already documents the single slug parameter with 100% coverage and provides a meaningful example. The description does not need to add much, but it does reinforce that the slug is expected to come from prior list/search calls.
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 a specific verb and resource: 'Get one complete essay by slug'. It also enumerates the contents of the result (Markdown-like body, metadata, licence context, canonical URL), which differentiates it from generic retrieval tools and sibling get_* tools.
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 gives explicit context for when to use the tool: after list_articles or search_articles has returned the slug. It does not explicitly discuss when not to use it, but the workflow guidance is clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower and credit goes to added context. The description adds a genuine behavioral guarantee — 'always present — what it does NOT establish and the observation that would retire it' — which tells the agent that falsification info is a non-optional part of the tool's contract. No contradiction with annotations.
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?
Two sentences with zero filler. The first sentence front-loads the resource, retrieval key, and full return shape using a colon list and em-dash emphasis for the 'always present' guarantee; the second sentence carries the usage guidance. Every clause earns its place, and the structure mirrors the tool's purpose of honest, limit-aware retrieval.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (so return values need not be described), rich annotations cover the mutation/safety profile, and parameter coverage is 100%, the description supplies what remains: the retrieval key format, the guaranteed content shape, and the two legitimate workflows. Nothing an agent needs to invoke this tool correctly or route itself to it is missing.
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%, so the baseline is 3 per the rubric. The description reinforces the id parameter by giving the concrete example format 'HE-CLAIM-001' and mentioning slug as an alternative, but it does not add substantive meaning beyond what the schema properties already document. It adequately confirms but does not compensate for any gap, because there is no gap.
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 opens with a specific verb and resource — 'Get one claim by id (HE-CLAIM-001) or slug' — and enumerates exactly what is returned: the statement, what it rests on, structured sources, what it does NOT establish, and the observation that would retire it. This distinctive return contract (limits + refutation) clearly separates it from sibling get_* tools that fetch other resource types such as patterns, articles, or architectures.
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 second sentence gives explicit use cases: 'Use this to cite the corpus honestly, or to check whether a result you have just measured confirms or falsifies a claim it makes.' This is clear contextual guidance that positions the tool relative to a workflow, though it does not explicitly name alternatives (e.g., list_claims for enumeration) or state when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by explaining that variants are 'returned side by side rather than merged,' which is not inferable from annotations or schema.
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 with no redundant wording. It front-loads the core operation, then adds useful content detail and a use case, all in a compact narrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only annotations and the presence of an output schema, the description covers all necessary selection and invocation guidance. It tells the agent what the route contains, when to use it, and how it differs from a merged view.
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 both slug and locale have descriptions. The description does not add parameter-level detail beyond the schema, so the baseline 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 states a specific verb and resource ('Get one route by slug') and details exactly what the route contains: reconstruction variants, ordered stops, hypotheses, confidence rubric, and sources. This clearly distinguishes it from sibling list/get tools.
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?
It gives an explicit use case: 'Use this to compare rival reconstructions of a voyage.' It does not explicitly name sibling alternatives like list_homeric_routes, but the 'one route by slug' scope and the compare-rival-reconstructions purpose provide strong contextual guidance.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'all' scoping and the list of returned fields, but does not reveal additional behavioral details such as pagination, result limits, or any implicit ordering. This is adequate but not rich, matching the calibration for safe read tools with annotation coverage.
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 with no filler. The first sentence states the action, resource, and output fields; the second provides routing guidance. Key information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) and has an output schema, so the description does not need to explain return values. It covers what the tool does, what it returns, and when to use it instead of the search sibling. Nothing needed for correct invocation is missing.
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%, and the sole parameter 'locale' is fully documented in the schema with an enum and default value. The description adds nothing about the parameter beyond what the schema already provides, so the baseline of 3 applies.
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 'List' with a clear resource, 'reference architectures (end-to-end enterprise agentic blueprints)' and enumerates the returned fields: id, slug, category, name, summary and provenance. This goes beyond the title and distinguishes the operation from generic browsing or searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Use this to browse the blueprints') and when to use the alternative ('use `search` when you have a use case rather than a name'). This gives an agent clear decision criteria for routing between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds useful behavioral context: claims carry confidence and underpinned units, are categorized by epistemic rung, and claim_type filtering narrows to checkable statements. No contradiction with annotations.
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?
Three sentences, each earning its place: the first defines what the tool returns, the second explains when to use it, the third gives filtering guidance. Front-loaded with the core verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with two optional enum parameters and an output schema, the description plus annotations fully cover purpose, usage, and parameter behavior. Nothing an agent needs to call it correctly is missing.
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?
Both parameters are fully documented in the schema with enums and descriptions, so schema coverage is 100%. The description adds a small semantic nuance ('claim_type' returns only what is checkable) but does not need to compensate for any schema gaps.
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 a specific verb ('List'), a specific resource ('load-bearing claims of the corpus'), and enumerates the exact tag types returned. This clearly distinguishes it from sibling tools like list_handbook or get_claim.
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?
It gives an explicit use-case ('Use this before quoting the handbook') and explains the value of filtering by claim_type to scope to checkable claims. It does not name alternatives or exclusions, but the context is sufficient for correct selection among siblings.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe, non-mutating behavior is covered. The description adds that the tool returns all governance units and the specific fields, which is useful but does not go beyond what annotations and schema already imply.
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?
Two sentences with no fluff: the first states the action, scope, examples, and returned fields; the second gives the browsing usage and routes to `search` for obligation/control lookup. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a single fully documented optional parameter, an output schema, and safety annotations, the description is complete. Nothing is missing for an agent to select and invoke this tool correctly.
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 only parameter, locale, has 100% schema description coverage with an enum and a clear default. The description does not repeat it, which is appropriate because the schema already fully documents the 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 opens with a specific verb and resource: 'List all AI governance units' and enumerates what those units are (regulations, standards, frameworks, playbooks) with concrete examples. It also states the returned fields (id, slug, category, name, summary), so an agent can clearly distinguish this from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives the intended use case: 'Use this to browse the regulations and standards.' It also names the alternative and the condition for choosing it: 'use `search` for an obligation or control.' This is clear routing guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful context beyond those annotations: that the list includes rival reconstructions with separate scores, and that these are reconstructed itineraries rather than definitive routes. This enriches the agent's understanding of the output without contradicting the annotations.
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?
Two sentences, both informative. The first sentence states the primary purpose and output content; the second gives a concrete usage scenario. There is no redundancy or filler, and the essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, a rich output schema, and comprehensive safety annotations, this description is complete. It explains what is listed, highlights the scoring of rival reconstructions, and tells the agent when to use it. Nothing critical is missing.
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?
With only one optional locale parameter and 100% schema description coverage (including an explicit enum), the schema fully documents the parameter. The description adds no additional parameter semantics, but none are needed since the locale parameter's meaning and allowed values are already explicit.
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 a specific action and resource: it lists reconstructed itineraries (nostos of Odysseus and the others), including rival reconstructions with separate scores. This clearly identifies what the tool does and distinguishes it from sibling list tools like list_homeric_places or list_homeric_episodes.
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?
It explicitly says to use this tool 'to see which voyages the atlas reconstructs before fetching one,' giving clear when-to-use context. It does not explicitly name the alternative get_homeric_route or state when not to use it, but the 'before fetching one' phrasing strongly implies the companion 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context that this is an 'all' listing and includes a catalogue-browsing field set, but it does not disclose behavior like pagination, ordering, or locale handling beyond what the schema already states.
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?
Two sentences with no wasted words. The first sentence front-loads the tool's core behavior and output fields; the second immediately gives usage guidance and the alternative. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only listing tool with a single optional parameter, a full output schema, and clear annotations, the description fully covers what an agent needs to select and invoke it correctly. It also disambiguates against the most similar sibling, search.
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% and the only parameter, locale, is fully documented with an enum and default value. The description adds no parameter-specific meaning, so the baseline of 3 applies.
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 names a specific verb (List), a precise resource (all Enterprise AI patterns), and the exact fields returned (slug, category, name, summary, provenance). This clearly distinguishes it as a catalogue-browsing tool rather than a lookup or search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this to browse the catalogue') and when to use an alternative ('use `search` when you are looking for a pattern that solves a problem'). This gives an agent clear selection criteria among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavior beyond annotations: it aggregates all surfaces in one call, reports that results name the next tool to call, and describes routing of calculator-shaped questions to Labs.
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 compact and front-loaded, stating the resource and scope in the first sentence, followed by guidance and expectations. Every sentence earns its place with no filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a broad search tool with an output schema, rich annotations, and 100% schema coverage, the description provides sufficient context: it tells the agent when to use it, what it searches, and what to expect from results. The routing behavior and cross-tool guidance complete the picture for correct 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?
Schema description coverage is 100%, and every parameter is already documented with clear semantics: query, locale, surfaces, and limit_per_surface. The description adds little parameter-specific meaning beyond reinforcing that all five surfaces are searched, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search') applied to every defined SANTISMM knowledge surface, enumerating the surfaces: core corpus, essays, Labs, epistemic claims, and Homeric Atlas. It also distinguishes itself by saying it covers more than 'only a core knowledge unit,' which separates it from narrower sibling search tools.
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 gives clear usage context: 'Use this first when a natural-language question might require a calculation, a long-form essay or a claim audit rather than only a core knowledge unit.' It also sets expectations about routing calculator-shaped questions to Labs, but it does not explicitly name sibling tools or formalize when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds that the tool works 'from explicit assumptions' and that a canonical_url is returned for citation, which are useful behavioral details beyond the schema. No contradiction with annotations.
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?
Two sentences with no filler: the deliverable list is front-loaded, the use case follows, and the currency/citation caveats are the last necessary details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter computational tool with a fully described schema and an output schema, the description covers selection, currency consistency, and citation behavior. It does not explain the calculation formulas, but that is not required for an agent to invoke it correctly.
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?
Schema coverage is 100%, so the baseline is 3; the description adds cross-parameter guidance by requiring all monetary inputs to be in the same currency and by framing inputs as explicit assumptions. This goes slightly beyond what individual property descriptions provide.
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?
States a specific verb (calculate) and enumerates the exact outputs: monthly operating cost, cost per verified outcome, manual baseline, savings, ROI, and break-even success rate. This makes the tool's purpose distinct from the many get_/list_ siblings and the other calculate_* tools in the same domain.
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?
Explicitly says 'Use this for an agent business case or scenario comparison', giving a clear selection context. It does not name the sibling calculate_* tools or give an exclusion criterion, but the intended use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value beyond those annotations by disclosing the locale-dependent return behavior: full entry vs. single-locale body. No contradiction with annotations.
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?
Two sentences, zero filler. The first sentence front-loads the core purpose and locale behavior; the second delivers actionable usage timing. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, read-only tool with an output schema, annotations, and fully documented parameters, the description covers purpose, behavior, and usage timing. A minor gap is not explicitly routing to alternative get_* sibling tools, but the 'knowledge unit' resource scope makes that differentiation implicit.
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?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds genuine meaning by explaining the behavioral consequence of locale ('full entry, or a single-locale body'), which goes beyond the schema's 'Language of the returned body' phrasing.
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+resource structure: 'Get one knowledge unit by slug.' It clearly distinguishes from sibling list/search tools by emphasizing single-item retrieval by slug, and the phrase 'Use this once search or list_knowledge has given you a slug' positions it precisely against its discovery-oriented siblings.
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 gives an explicit precondition for use: after `search` or `list_knowledge` yields a slug. This is clear context that prevents an agent from calling it prematurely. It does not explicitly enumerate exclusions (e.g., that get_pattern/get_article are for other resource types), but the knowledge-unit scope makes those alternatives obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context by specifying that the tool returns a 'complete MCP map' and listing what that map contains, reinforcing that this is a read-only, non-mutating 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 two concise sentences with the key usage instruction front-loaded. Every phrase adds value: the scope, the surfaces, and the included metadata are all packed without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is sufficiently complete: it names what the agent receives, why to call it, and where it fits among many sibling tools. It does not detail the output schema's shape, but the presence of an output schema covers that.
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 and an empty input schema, so the schema fully covers parameter semantics. There is nothing more the description needs to explain, and the lack of parameters makes the 'start here' instruction unambiguous.
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 and resource: 'Get the complete MCP map' and says to 'start here.' It further distinguishes the tool by enumerating the five-domain core and four separate surfaces, making its scope clear and different from the many individual get_* and list_* sibling tools.
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 'start here' in both the title and description provides clear guidance that this tool is the intended entry point before using domain-specific tools. It does not explicitly list exclusions or alternatives, but for an overview tool this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context beyond annotations by specifying what the returned body includes and that it composes patterns/knowledge. This is meaningful but not extensive; a 4 is appropriate given the annotation coverage.
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?
Two tightly written sentences with no filler. The primary action and resource scope are front-loaded, and the usage guidance is delivered in a short second sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, read-only annotations, and well-documented parameters, so the description does not need to restate those. The description completes the missing context: why this tool exists in the workflow, what content it returns, and when to call it. No important guidance is absent for an agent to invoke it correctly.
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%, and both `slug` and `locale` already have clear descriptions in the input schema. The tool description adds the workflow context of using a slug obtained from search/list, but it does not add new parameter-level meaning beyond the schema. Baseline 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 states a specific verb ('Get'), a specific resource ('one reference architecture'), and the identifying key ('by slug'). It also enumerates the returned content (request flow, reference scenario, KPIs, cost & scaling, patterns/knowledge), making it clearly distinguishable from sibling tools like list_architectures or get_knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: once `search` or `list_architectures` has produced a slug. This provides a clear prerequisite and names the discovery siblings that should precede it, leaving no ambiguity about the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds value beyond this by specifying what the returned governance unit includes: scope, key requirements, implementable controls, a checklist, and common pitfalls. This gives the agent a concrete idea of the response's substance without contradicting any annotation.
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?
Two sentences with no filler: the first front-loads what the tool returns, and the second gives actionable workflow guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool, the description is complete: it names the lookup key, states the workflow, summarizes the payload, and the output schema covers return details. The annotations cover safety and idempotency, so nothing critical is missing.
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%, so both `slug` and `locale` are already fully documented. The description only echoes the slug-based lookup and adds no additional parameter-level meaning, so the schema carries the burden and the baseline of 3 applies.
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 a specific verb ('Get'), a specific resource ('one AI governance unit'), and the lookup mechanism ('by slug'). It also lists the returned content areas, which makes the tool's purpose concrete and distinguishes it from list-oriented siblings like list_governance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a usage workflow: use this tool once `search` or `list_governance` has returned a slug. This directly prevents misuse by telling the agent when the tool is appropriate relative to its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail by stating that the tool 'Returns the full Markdown body plus its provenance and related ids,' which is not evident from the annotations alone.
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 with no filler. The core action and distinguishing lookup-by-id behavior are front-loaded, and the usage guidance is included without redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only tool with a full input schema, safety annotations, and an output schema, the description is complete. It explains what the tool returns, how to identify a chapter, and when to use it, leaving no critical gap for an agent to call it correctly.
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%, and both the id and locale parameters already include descriptive text, including the id-or-slug semantics and the 'Default: en' for locale. The description reinforces this but adds little beyond what the schema provides, so a baseline 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 states a specific verb and resource: 'Get one Harness Engineering Handbook chapter,' and clarifies lookup by 'id (e.g. 'HRN-001') or slug.' It is clearly distinct from sibling listing tools like list_handbook and search_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this once search or list_handbook has given you an id.' This tells an agent that this tool is for retrieval after discovery, not for browsing or searching, and names the tools that should be used first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral nuance: a place the poem does not locate carries no coordinates at all, and every proposed identification is listed with its own coordinates, class, rubric, and sources. This informs the agent about unexpected data shape and evidential richness.
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 compact: a single opening sentence defining the operation and output, followed by one sentence giving usage conditions. Every clause earns its place, with no repetition of schema or annotation content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the annotations cover safety and idempotence, the description provides what remains needed: purpose, usage context, and a key edge case about unlocated places. The tool is simple enough that this is fully sufficient.
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 provides 100% coverage for both parameters, including the slug example and locale enum. The description reinforces 'by slug' but does not add new detail beyond the schema, so the baseline 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 ('Get one place by slug') and the resource ('place'), and differentiates from the sibling list_homeric_places by emphasizing singular retrieval by slug. It also previews what is returned, making the tool's purpose unmistakable.
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 tells the agent when to use this tool: 'when you need to weigh the evidence for a location, or to cite it.' It does not explicitly mention alternatives or exclusions, so it stops short of a 5, but the intended use cases are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral detail by listing the retrieved content and noting the executable endpoint is included only 'when one exists', plus direction to avoid reimplementing formulas. This is a clear, non-contradictory addition beyond the annotations.
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?
Two sentences carry purpose, scope, usage sequencing, and an alternative-behavior warning with no filler. Every phrase contributes to correct tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema and rich annotations, the description is complete: it specifies what the tool returns, when to call it, and how it relates to sibling tools. No critical missing context prevents correct 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?
The only parameter, slug, has 100% schema description coverage with an example. The description adds 'by slug' and implies the slug comes from list_labs or search_all, but it does not need to elaborate further because the schema already documents the parameter fully. Baseline 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 states a specific verb and resource: 'Get one Lab by slug', and enumerates exactly what is included (formulas, assumptions, related SANTISMM content, executable endpoint). It is clearly differentiated from the many sibling get_* tools by naming the Lab resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: use after list_labs or search_all, and use a named calculate_* tool rather than reimplementing a published formula. This tells an agent both when to call this tool and when to prefer an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is well covered. The description adds behavioral context beyond annotations by stating the full scope ('every long-form essay') and the kind of output ('citable canonical URLs'). This is useful and non-redundant, though it doesn't discuss pagination or rate limits—minor given the read-only idempotent nature.
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?
Two sentences with zero filler: the first states the core function and return fields, the second gives usage routing. The key information is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter and an output schema, the description fully covers what, where, and when to use it. It even names the alternative tool for a different use case. No critical information is missing.
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%, so the locale parameter is fully documented in the schema (enum and meaning). The description does not add further parameter semantics beyond what the schema already provides, which fits the 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 uses a specific verb ('List') and identifies a concrete resource ('every long-form essay published on articles.santismm.com') along with the data returned (language, dates, topics, canonical URLs). It clearly distinguishes itself from the sibling 'search_articles' by contrast, so an agent can tell them apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this to browse the essay catalogue; use `search_articles` when you have a topic rather than a slug.' This tells the agent both when to use this tool and when to prefer the alternative, leaving no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this returns a 'chapter map' rather than full content and enumerates the chapter topics, which is useful behavioral context beyond the structured fields.
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?
Two sentences, both purposeful. The first states the action and scope, the second gives usage routing. Every word earns its place, and the most decision-relevant instruction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter list tool with rich annotations and an output schema, the description fully covers what an agent needs: purpose, scope, and when to choose a different tool. No missing return-format information because the output schema exists.
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 only parameter, 'locale', is fully documented in the schema with an enum and default value. The description adds no extra parameter detail, so the baseline of 3 applies because 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 opens with a specific verb and resource, 'List the Harness Engineering Handbook chapters (HRN-001…)', and clarifies the resource's scope as a canonical long-form corpus. It also names its sibling 'search' and explains the distinction, so an agent can tell list_handbook apart from related tools without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use ('Use this to see the chapter map') and when-not-to-use ('use `search` when you have a topic rather than a chapter'), naming the alternative tool directly. This leaves no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond those flags: it returns every episode, in a deterministic reading order, with completeness implied by 'every' and aligned with the `openWorldHint: false` signal. There is no contradiction with annotations.
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?
Two sentences deliver the core action, the result contents, the ordering behavior, and the routing to the sibling tool. Each clause earns its place, and the primary purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional and fully described parameter, an output schema available, and annotations covering safety, the description is complete. It tells the agent exactly what the list contains, how it is ordered, and how to proceed if detail is needed.
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 parameter `locale` is fully documented in the input schema, including its enum values and default behavior. The description adds no parameter-level detail, but none is needed because the schema already covers 100% of parameter 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 names a specific verb ('List'), a specific resource ('every episode of the Iliad and the Odyssey held in the atlas'), and defines the output shape: reading order, passage, places, and locatability. It also explicitly distinguishes itself from `get_homeric_episode`, so an agent can tell the list operation from the detail operation without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct selection guidance: 'Use this to find the episode you want; use `get_homeric_episode` for its theories and sources.' This tells the agent both when to choose this tool and when to choose the sibling alternative, which is explicit and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context by specifying that it returns all knowledge units and includes Evidence-First provenance, which goes beyond the annotations. It does not contradict the annotations.
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-loads the core action and fields, and wastes no words. The usage guidance is integrated cleanly at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional, fully documented parameter and an output schema, the description provides enough context for correct invocation and tool selection. The explicit sibling guidance covers the main ambiguity an agent might face.
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% for the single optional `locale` parameter, including its enum values and default. The description adds no parameter-level detail, but it does not need to because the schema fully documents the 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 uses a specific verb ('List'), a clear resource ('all knowledge units'), and specifies the returned fields ('slug, category, title, summary and Evidence-First provenance'). It also differentiates itself from the sibling `search` tool by framing the purpose as browsing the domain rather than answering a specific question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'Use this to browse the domain'. It also provides an alternative and the condition for choosing it: 'use `search` when you have a question rather than a slug.' This gives clear, actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety and side effects. The description adds behavioral context by stating it lists every Lab and includes formulas, assumptions, and citation URLs; this goes beyond the annotations without contradicting them.
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?
Two dense sentences: the first front-loads the action and payload, the second gives the use case and filter condition. There is no repetition of schema or annotation data and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional enum parameter, strong annotations, and an output schema, the description covers what is returned, why to use it, and when to apply the filter. The output schema handles return-structure details.
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 only provides an optional kind enum with 0% description coverage, so the description must carry the meaning. It says the parameter filters by kind and maps it to the exact user intents: calculator, converter, experiment or educational game. The enum itself lists allowed values, so deep per-value explanation is not necessary.
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?
States a specific action and resource: 'List every SANTISMM Lab', and names what each entry contains: inputs, outputs, assumptions, formulas and citation URL. This distinguishes it from get_lab and other list/get siblings by promising a complete enumeration with a defined payload.
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?
Explicitly frames it as a discovery tool: 'Use this to discover interactive and machine-readable tools' and says to 'filter by kind when the user specifically asks for a calculator, converter, experiment or educational game.' It gives clear when-to-use context, though it does not state when to prefer get_lab or search_all instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context: the meaning of 'every place,' the definition of each identification class, and the crucial caveat that confidence is an editorial 0-12 judgement, not a probability. This goes beyond what annotations provide.
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?
Every sentence earns its place: the first states scope and output, the second gives usage guidance, and the third and fourth define the domain-specific vocabulary (classes and confidence rubric) that the agent needs to interpret results. It is detailed but not bloated, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the one-parameter schema, rich annotations, and the presence of an output schema, the description fully covers what an agent needs: scope, field meanings, classification semantics, confidence interpretation, and routing to the detail-level sibling. Nothing critical is missing.
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% for the single optional `locale` parameter, which already documents its enum values, default, and purpose. The description does not discuss the locale parameter, but because the schema fully covers it, the baseline 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 states a specific verb ('List'), a specific resource ('every place in the Homeric Atlas'), and the exact fields returned (identification class, confidence score, competing identifications). It also explicitly differentiates itself from the sibling `get_homeric_place`, so an agent can tell them apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives explicit routing guidance: 'Use this to browse the atlas; use `get_homeric_place` once you have a slug.' This clearly tells the agent when to choose this tool over the closely related sibling and requires no inference.
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:

[![santismm-knowledge-mcp MCP server](https://glama.ai/mcp/servers/santismm/santismm-knowledge-mcp/badges/card.svg)](https://glama.ai/mcp/servers/santismm/santismm-knowledge-mcp)

Score Badge

Copy to your README.md:

[![santismm-knowledge-mcp MCP server](https://glama.ai/mcp/servers/santismm/santismm-knowledge-mcp/badges/score.svg)](https://glama.ai/mcp/servers/santismm/santismm-knowledge-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/santismm/santismm-knowledge-mcp'

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