History of Alexandria, Egypt: search the archive, read articles, find events and prints.
Scored across 8 tools
Most tools target clearly distinct resources: articles, institutions, licensing, store products, events, and archive search. There is some overlap because search_archive also covers articles and events, while list_recent_articles and list_upcoming_events provide filtered views, but the descriptions make the intended boundaries mostly clear.
All tool names follow a consistent verb_noun pattern using snake_case: get_*, list_*, and search_*. The convention is predictable throughout with no mixed styles.
Eight tools is well-scoped for a public archive discovery server. Each tool has a clear role, and the set avoids both excessive fragmentation and thin coverage.
Core discovery is covered: search, article retrieval, institution listings/details, licensing, events, and store products. However, there is no direct get_archive_item for photographs/documents/maps beyond articles, and no get_event or get_product detail tools, which are notable retrieval gaps for a complete public archive surface.
Fetch one published article by numeric id — returns a public preview in Arabic and English plus metadata. Sign in on the website to read the full article.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Article id (from search results or list_recent_articles). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond annotations: the response is only a public preview in Arabic and English, and full content requires signing in on the website. It does not cover behavior for missing, unpublished, or private article ids, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core operation front-loaded and the access limitation immediately following. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns and does so at a high level: a public preview in Arabic and English plus metadata. For a single-parameter read tool this is largely sufficient, though it leaves the exact response shape vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'id' parameter already has a clear description including where to source it. The description reinforces that the id is numeric and refers to a published article, but adds no further syntax or constraint 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch one published article by numeric id') and immediately scopes what is returned ('public preview in Arabic and English plus metadata'). The word 'one' and the id-based lookup clearly distinguish it from list-style siblings like list_recent_articles and search_archive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a numeric article id, and the sign-in note clarifies a limitation, but it never states when to prefer this tool over siblings or what to do if you lack an id. Alternatives such as list_recent_articles or search_archive are mentioned only in the parameter schema, not in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single institution by its slug — description, history, contact details, and a sample of its published archive items with canonical URLs. Use this to answer questions about a specific institution's holdings, or to find items available for licensing.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Institution slug (from list_institutions or a URL). | |
| itemLimit | No | Sample size (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real value by disclosing the shape of the response — a bounded 'sample' of published items with canonical URLs — which tells the agent results are partial, not exhaustive. It does not mention pagination, truncation behavior beyond the sample, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence for what the tool returns, one for when to use it. Front-loaded with the verb and resource, no filler, nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns, and it does so adequately: entity fields plus a bounded sample of archive items with canonical URLs. Minor gap: it doesn't say whether the sample is paginated or how the item limit interacts with the broader collection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented (including the default of 20 and max of 50 for itemLimit). The description's phrase 'a sample of its published archive items' conveys the purpose of itemLimit but adds no syntax or constraint detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (fetch), resource (a single institution by slug), and enumerates what comes back (description, history, contact details, sample archive items with canonical URLs). 'Single institution by slug' implicitly contrasts with the list_institutions sibling, but it never names that sibling explicitly, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Two concrete use cases are given: answering questions about a specific institution's holdings and finding items available for licensing. This is clear positive guidance, but there are no exclusions or named alternatives (e.g. when to prefer search_archive or list_institutions instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain how an image or document from the Alexandria Archive may be reused or licensed (publication, broadcast, commercial use), and where the request is made. Pass itemId for one archive record; omit it for the general terms.
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | No | An archive record's id, from search_archive or its URL (/archive/{id}). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the output is procedural/terms information ('where the request is made') rather than raw data, but discloses nothing about latency, coverage, or authoritative source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence naming the resource and scope, followed by a compact clause on parameter behavior. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional parameter, read-only tool with no output schema, the description covers purpose, both invocation modes, and the nature of the returned content. Only minor details (e.g., whether general terms are archive-wide) are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents that itemId is an archive record id. The description goes beyond that by explaining the semantic difference between supplying it (per-item terms) and omitting it (general terms), which is real added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (explain) and resource (reuse/licensing terms for archive images or documents), and scopes the answer to publication, broadcast and commercial use. An agent can immediately tell this apart from retrieval siblings like search_archive or get_article.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing clause gives explicit usage guidance: pass itemId for a single record, omit it for the general terms, which effectively defines the two invocation modes. It does not name an alternative tool or state when licensing questions should be routed elsewhere, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List museums, libraries, archives and other institutions that publish their collections on the Alexandria Archive. Returns name, type, item count and canonical URL.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional filter, e.g. 'museum', 'library', 'archive', 'university'. | |
| limit | No | Max results (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds real value by disclosing the returned fields (name, type, item count, canonical URL) and the domain scope, which is meaningful since no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: the first states scope, the second states the return payload. Both are front-loaded and neither repeats the name or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-required-parameter read tool with no output schema, the description supplies the two things an agent actually needs: what qualifies for inclusion and what fields come back. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – both the type filter and its example values, plus the limit bounds and default, are already documented in the schema. The description enumerates the same institution types but adds no syntax or format detail beyond it, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ("List museums, libraries, archives and other institutions") and scopes it to partners publishing on the Alexandria Archive. The plural form distinguishes it from the singular sibling get_institution without needing to name it. It stops short of explicitly differentiating from search_archive or the other list_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the scope phrase (institutions that publish collections here), and the existence of get_institution makes the browse-vs-fetch split inferable. However, there is no explicit when-to-use guidance, no mention of when to prefer search_archive, and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recently published articles (id, title, excerpt, date, URL).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered without the description. The description adds the field list of what comes back, which is modestly useful, but says nothing about ordering guarantees, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the verb and resource and ending with the return fields. Nothing is wasted and nothing important is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully lists the returned fields, and the single optional limit parameter is fully covered by the schema. The only gap is the lack of differentiation from search_archive for an agent choosing among seven siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single self-documenting 'limit' parameter (default 10, 1-50), so the schema carries the burden. The description adds no meaning beyond it, which is the baseline-3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (recently published articles) and enumerates the returned fields (id, title, excerpt, date, URL). It is clear but never references the sibling search_archive, so an agent must infer the distinction between 'recent' listing and archive searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The adjective 'recently published' implies a recency-based, unfiltered listing, which is weak guidance for choosing over search_archive. There is no explicit when-to-use or when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products on sale in the Alexandria Archive's store — prints, books and gifts about the city — with price in Egyptian pounds and the product page. Sales support the archive.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 12). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context about what is returned (price in EGP, product page link) but says nothing about pagination or ordering behavior beyond what the limit schema already documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that conveys the resource, content types and return fields efficiently. The trailing clause about sales supporting the archive is mild flavor rather than functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, non-open-world list tool with a fully documented single parameter and no output schema, the description supplies everything an agent needs to invoke it correctly. Only minor details like default ordering are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema description coverage, so the schema fully documents limit, its default and its 1-30 range. The description adds no parameter meaning, which is acceptable at this coverage level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (products in the archive's store), and enumerates content types (prints, books, gifts) plus what is returned (price in EGP, product page). No sibling tool covers the store, so it is unambiguously distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use it (browsing shop merchandise), but there is no explicit guidance, no prerequisites, and no mention of alternatives such as search_archive. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Alexandria Archive's upcoming events — heritage walks, workshops, talks — soonest first, with date, place, price in Egyptian pounds (or free) and the page where a person books a seat. Use for questions like 'what is on in Alexandria this week' or 'a history walk in Alexandria'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false). The description adds real behavioral value on top: results are sorted soonest-first and each entry carries date, place, price in EGP or free, and the booking page. It omits any statement about result limits or pagination behavior, which the default-10 limit makes relevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the resource and its sort/return shape front-loaded; the example questions are the only mildly redundant part and they do reinforce usage. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns and does so: ordering, per-event fields, currency handling ('or free'), and the booking link. For a simple one-parameter list tool this is complete enough to call confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (limit) and the schema already documents it fully at 100% coverage with a default and range. The description says nothing about limiting result counts or truncation behavior, so it adds no meaning beyond the schema. Baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('List the Alexandria Archive's upcoming events') plus the exact category of items ('heritage walks, workshops, talks'). It is clearly distinguishable from siblings like list_recent_articles and search_archive without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger questions ('what is on in Alexandria this week', 'a history walk in Alexandria') that map cleanly onto this tool. It does not name an alternative sibling or state when NOT to use it, so it falls short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search historical photographs, documents, maps, articles, and events of the Alexandria Archive. Query can be Arabic or English (e.g. 'Stanley Bridge', 'كوم الدكة'). Returns titles and canonical URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms, Arabic or English. Min 2 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, non-destructive, closed-world), so the bar is lower; the description adds that queries accept Arabic or English and that results are titles plus canonical URLs, which is valuable given there is no output schema. It omits result count limits and pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the resource scope and ending with the return format. The Arabic/English note slightly duplicates the schema's own parameter description, but the example queries justify the space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only search, the description supplies the missing return-format information (titles and canonical URLs) in lieu of an output schema, and clarifies language support. Only result limits and pagination, if any, remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is a single parameter, so the schema already documents the query string and its 2-character minimum. The description's language note and example queries ('Stanley Bridge', 'كوم الدكة') add only marginal illustrative value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and names the resource and its content coverage (photographs, documents, maps, articles, events). It is clearly distinguishable from the get_*/list_* siblings, which retrieve or enumerate rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer that this is the discovery entry point and get_article is the follow-up retrieval. There is no explicit statement of when to prefer search over list_recent_articles or list_upcoming_events, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_articleget_institutionget_licensing_infolist_institutionslist_recent_articleslist_store_productslist_upcoming_eventssearch_archiveSearch LOC digital collections, Chronicling America newspapers (full OCR), and LC Subject Headings.
Search 497,000+ public domain paintings, prints and drawings from 72 museums, with museum records.
Evidence-first news archive: briefs, breaking news, search, Palestine claims, conflict monitor.
Reddit Archive — historical Reddit post and comment search, and subreddit activity over time…
Add one secure layer between your agents and this server.