Vancouver house histories by address: who lived there each year to 1945, permits and the 1912 map.
Scored across 3 tools
The three tools have mostly distinct roles: coverage explains what is indexed, find_house resolves an address or surname to a house path, and house_history returns detailed historical information for a house. There is minor overlap because find_house may return covered-street context and coverage references street pages, but an agent can still choose the right tool in most cases.
All names use snake_case, but the grammatical patterns are mixed: coverage is a noun, find_house is verb_noun, and house_history is noun_noun. The names remain readable, but they do not follow a predictable verb_noun convention throughout.
Three tools are reasonably scoped for a niche historical address lookup service, with each tool covering a distinct part of the workflow. The surface is a bit minimal, but it avoids unnecessary bloat.
The tool set covers coverage discovery, address/surname lookup, and detailed house history, which are the core operations for this domain. Minor gaps exist, such as no dedicated street-browsing or reverse-lookup tool, but the main research workflow is supported.
The Vancouver streets, blocks and directory years AddressLore covers, with each street's page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scope information (it covers streets, blocks, and directory years, and each street has its own page), but says nothing about result size, ordering, or the shape of the returned coverage data.
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 short sentence with no padding, front-loading the geographic scope. The trailing clause 'with each street's page' is slightly cryptic but does not bloat the text.
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 zero-parameter discovery tool with no output schema, the description is minimal but barely adequate. It does not explain what the response looks like or what an agent should do with 'each street's page', leaving a gap the structured fields cannot fill.
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 tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 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 identifies the resource (Vancouver streets, blocks and directory years) but uses a noun phrase with no verb, so it never states what the tool actually does (return a list? a summary? links?). It is distinguishable from find_house and house_history by being about coverage scope rather than a specific property, but the action remains implied 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?
There is no indication of when to call this tool versus find_house or house_history, nor any precondition such as 'call this first to see if a street is covered'. The agent must infer the use case entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a Vancouver address, or a resident's surname from 1945 or earlier, in AddressLore's coverage. Returns the matching house's path for house_history, or says plainly that the address isn't covered (never a nearby house in its place), with the covered streets.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | An address ("526 Keefer Street") or a surname ("Clandenning"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, and the description still adds meaningful behavior: negative results are reported plainly, a nearby house is never substituted, and covered streets are returned on a miss. It does not disclose matching semantics such as case sensitivity, exact-vs-partial address matching, or ambiguity handling for common surnames.
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 tight sentences, front-loaded with the lookup scope and followed by the return behavior. Every clause carries information an agent needs: accepted inputs, the handoff target, and the miss contract.
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 and a single required parameter, the description carries the return contract itself and does so reasonably: a house path for house_history, or an explicit not-covered message plus covered streets. The only softness is what 'path' concretely contains, which the sibling tool's definition presumably resolves.
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% for the single `query` parameter, so the baseline is 3. The description does add real meaning beyond the schema by imposing the '1945 or earlier' constraint on surname queries, which the schema does not state, but it offers no input formatting guidance (quoting, street-type spelling) for the address form.
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 (look up) and a specific resource (a Vancouver address or pre-1945 resident surname) against AddressLore's coverage, and names the downstream tool house_history. It does not explicitly distinguish itself from the sibling `coverage` tool, even though the miss-path mentions returning 'the covered streets', which superficially overlaps with that sibling.
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 clear activation conditions: an address, or a surname from 1945 or earlier, and routes the agent onward to house_history once a match is found. It stops short of saying when to call `coverage` instead of this tool, so the boundary with that sibling 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.
When a covered Vancouver house was built and what stood there: the building permit (1901–1930) and the City's year built, what the 1912 fire insurance map draws on the lot and whether today's building is very likely that one, what stands today, and who lived there in each directory year with each listing's source page, and where the 1921 census lists households at the address (Strathcona), their people, rent, rooms, origins and birthplaces as counts, never names. Residents' names through 1945 only; later years show a household and job without names. Anything inferred is marked inferred.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | A Vancouver street address as written today or in the directories ("620 Keefer St", "2649 Yew"), an AddressLore house path ("620-keefer") or its URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, non-open-world operation. The description adds substantial behavioral context beyond that: permit years 1901–1930, directory-year residents with source pages, names only through 1945, census data as counts rather than names, and explicit marking of inferred data. It does not cover error behavior for uncovered addresses, but the data limitations are unusually well disclosed.
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 core purpose and every clause carries substantive information about the returned history. It is a single long run-on sentence, however, so the dense enumeration of output categories could be structured more readably.
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 returned content, and it does so thoroughly: permits, map evidence, current building, directory residents, and census aggregates. It is complete enough to call correctly, though it omits sibling-tool routing and does not explain behavior for addresses outside the covered set.
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 single `address` parameter is fully documented in the schema, including accepted formats such as street address, AddressLore path, and URL. The description does not add syntax or format guidance beyond the schema, so the high schema coverage makes 3 the appropriate baseline.
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 clearly states a specific resource and scope: the history of a covered Vancouver house, including build year, permits, fire-insurance-map evidence, current building, directory residents, and 1921 census counts. It is far more specific than the title alone, but it does not explicitly differentiate this tool from its siblings `find_house` and `coverage`.
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 phrase 'covered Vancouver house' and the historical-data scope, so an agent can infer this is the tool for house-history lookups. However, the description gives no explicit when-to-use guidance, no exclusions, and no routing to `find_house` or `coverage` for address resolution or coverage checks.
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.
coveragefind_househouse_historyVancouver building permits and new business licence leads for sales prospecting via Apify.
Zoning, parcel, and development feasibility for a street address in Canada and the US.
U.S. building permits, permit histories by address and contractors from city and county records.
Building-permit verdicts by address, with cited records. SF, Seattle, Austin, NYC. Pay per call.
Add one secure layer between your agents and this server.
