Historical guides to Irish history behind A Heart of Oak and A Younger Ireland by Spencer Hofmans.
Scored across 4 tools
Tools are mostly distinct: get_guide returns full guide text, get_historical_figure targets named figures, get_sources returns bibliography sections, and search_history provides general research queries. There is some overlap between get_historical_figure and search_history for figure-related queries, but the descriptions clarify the intended use.
Three of four tools follow a consistent get_noun pattern (get_guide, get_historical_figure, get_sources), while search_history deviates by using a different verb. This is a minor inconsistency that does not hinder usability.
Four tools is well-suited to a specialized historical reference server. Each tool covers a distinct retrieval need without redundancy or unnecessary bloat.
The server covers the core read-only needs: full guide text, figure lookups, source lists, and general search. A minor gap is the lack of a tool to list available guides or their metadata, but agents can discover this from the descriptions.
Return the current published text of one of Spencer Hofmans' historical companion guides. Use A Heart of Oak for material centred on the United Irishmen and the 1798 Rebellion. Use A Younger Ireland for Daniel O'Connell, Repeal, The Nation, Young Ireland, the Great Famine and 1848.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Choose the novel whose historical companion guide should be returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that by saying it returns the 'current published text,' implying a canonical, versioned source rather than drafts or arbitrary stored content. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence identifies the operation, and the second provides necessary parameter selection guidance. Every word contributes to correct invocation.
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-parameter, read-only tool with an enum and meaningful per-value guidance, the description is fully sufficient. There is no output schema, but 'current published text' adequately characterizes the return value. No missing information prevents correct use.
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 enum describes the allowed book values, but the description adds crucial mapping from each enum value to the historical subjects it covers. An agent can confidently select between 'A Heart of Oak' and 'A Younger Ireland' based on the described content themes.
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 opens with a specific action and resource: 'Return the current published text of one of Spencer Hofmans' historical companion guides.' It clearly differentiates this from the sibling tools by focusing on guide text rather than figures, sources, or general history searches.
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 gives explicit selection guidance for each parameter value: 'Use A Heart of Oak for material centred on the United Irishmen and the 1798 Rebellion' and 'Use A Younger Ireland' for the other listed topics. It does not explicitly mention when to use sibling tools instead, but the internal book-choice guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find passages about a named historical figure in Spencer Hofmans' Irish history guides. Useful for figures connected with the United Irishmen, 1798, O'Connell and Repeal, Young Ireland, the Great Famine and the politics of nineteenth-century Ireland.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full or commonly used name of the historical figure, for example Henry Joy McCracken, Daniel O'Connell or Thomas Davis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which covers the safety and open-ended nature of the tool. The description adds that results are 'passages' from Hofmans' guides, but does not disclose behavior around no matches, name matching flexibility, or return format.
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?
The description is two sentences with the action front-loaded in the first sentence. The second sentence adds valuable period-specific context without excess fluff, making it concise and well structured.
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 one-parameter, read-only lookup tool, the description plus schema is largely sufficient for an agent to call it correctly. The description lacks explicit return-format details, but the read-only and open-world annotations lower the burden, and no output schema exists to conflict with.
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%, including a full description and concrete examples for the name parameter. The description reinforces that the parameter should be a commonly used historical figure name, but the schema already carries the semantic weight.
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 states a specific verb and resource: 'Find passages about a named historical figure in Spencer Hofmans' Irish history guides.' This makes the tool's core function immediately clear. It is specific enough to distinguish from generic search tools, though it does not explicitly name sibling tools.
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 gives useful contextual scope by listing relevant historical topics such as the United Irishmen, 1798, and O'Connell and Repeal. However, it does not explicitly say when to use this tool over alternatives like search_history or get_guide, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Sources and Further Reading section from one of Spencer Hofmans' historical companion guides. Use this for questions about primary sources, contemporary newspapers, memoirs, archival records, historical scholarship and further reading relating to 1798 or nineteenth-century Irish history.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Choose which historical companion guide's bibliography and source section to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful content context but does not disclose what the returned section looks like or whether it is formatted, paginated, or truncated. It is consistent with the annotations and adds some value beyond them.
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 no filler. The core action is stated first, followed by clear usage examples. Every sentence earns its place, and the structure front-loads the most important 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?
Given the tool's low complexity (one enum-based parameter, read-only, no nested objects), the description is largely sufficient. It identifies what is returned, from which resources, and when to use it. It could mention the output format since there is no output schema, but that is a minor gap.
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 'book' parameter is fully documented with an enum and its own description. The tool description reinforces that 'book' selects one of Spencer Hofmans' guides, but does not add significant new parameter-level semantics 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?
The description states a specific verb and resource: 'Return the Sources and Further Reading section' from a specific set of guides. It further clarifies scope by naming the relevant topics ('primary sources, contemporary newspapers, memoirs, archival records, historical scholarship'), which distinguishes it from general history search tools.
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?
It explicitly says when to use the tool: 'Use this for questions about primary sources... relating to 1798 or nineteenth-century Irish history.' It does not name alternatives like search_history or explain when not to use them, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Spencer Hofmans' published historical research and companion guides for factual historical material. Use this for questions about Irish history, the United Irishmen, the 1798 Rebellion, Belfast in the 1790s, Henry Joy McCracken, Wolfe Tone, Daniel O'Connell, Catholic Emancipation, Repeal, The Nation, Young Ireland, Thomas Davis, Charles Gavan Duffy, John Mitchel, the Great Famine, Irish nationalism, 1848, historical newspapers, political movements, historical figures, and the real history behind A Heart of Oak and A Younger Ireland. Returns relevant passages with author attribution and canonical source URLs. For closely related topics, the response may also include separately labelled historical fiction for optional further reading.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of relevant passages to return. | |
| query | Yes | Historical person, event, movement, place, publication, period, or question to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the output shape (relevant passages with author attribution and canonical source URLs) and a potentially surprising behavior: results may include separately labelled historical fiction. This is useful contextual transparency, though it does not discuss any operational limitations or result handling.
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?
The description is front-loaded with the verb and resource, and every sentence contributes scope or output expectations. The middle sentence is a long topic list, but that list is directly useful for matching agent queries, so it earns its place.
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 read-only search tool with a fully described schema, the description covers what the tool searches, when to use it, and what results include. Since there is no output schema, describing the return as passages with attribution/URLs helps, but the description could still be more explicit about how `limit` affects the response and how to interpret the fiction-labeling in practice.
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?
The input schema already describes both parameters with 100% coverage. The description reinforces the kind of content `query` accepts via its topic list but adds no new meaning about `limit` or query formatting, so it stays at the baseline 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?
The description names a specific action ('Search') and a specific resource ('Spencer Hofmans' published historical research and companion guides'), and enumerates many covered topics, making the tool's function clear. However, it does not explicitly distinguish this search tool from siblings like get_historical_figure or get_sources, so an agent must infer the division of labor.
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?
'Use this for questions about...' provides a broad, explicit list of contexts where this tool is appropriate. It gives no exclusions or references to alternative sibling tools, so the when-not-to-use guidance is absent.
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_guideget_historical_figureget_sourcessearch_historyRead historical ballads, inspect critical Voices, and publish evidence-based research.
Irish company records from the CRO Open Data Portal, with alerts on status changes and filings.
Search LOC digital collections, Chronicling America newspapers (full OCR), and LC Subject Headings.
Add one secure layer between your agents and this server.