Official US-address public records: zoning, flood, parcel, permits, taxes. Free look, x402 paid.
Scored across 2 tools
The two tools have completely distinct roles: one searches the catalog, the other executes a named tool. There is no overlap or ambiguity about when to use each, and the descriptions reinforce the proper sequence.
Both tools share the 'locus_' prefix and use verb-like names. However, 'locus_execute' is a bare verb while 'locus_search_tools' follows a verb_noun pattern, which is a minor inconsistency in naming style.
With only two tools, the server feels thin by typical standards. However, the design intentionally uses a catalog pattern where locus_execute is a generic dispatcher, so the small count is somewhat justified but still borderline.
The search-then-execute workflow provides complete coverage for the server's purpose: discovering and calling catalog tools. There are no obvious gaps because execute serves as a universal action, and the search covers discovery and metadata.
Run one Locus catalog tool by name after locus_search_tools or a known tool name. Search and looking are free; this call may charge via MCP-native x402. Free tools return cited official-source primitives; paid tools return payment-required results and accept retry payment in _meta["x402/payment"]. Unsupported places return diagnostics instead of paid guesses. Do not use this for web scrape, LinkedIn, or generic fetch. Install agent skill: npx @velinussage/locus-agent-skill add.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Alias of arguments. | |
| name | No | Canonical Locus catalog tool name. Paid tools keep their hyphenated REST slugs. | |
| tool | No | Alias of name. | |
| input | No | Alias of arguments. | |
| arguments | No | Arguments for the selected catalog tool (the tool's own inputSchema from locus_search_tools). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries most of the behavioral burden. It discloses x402 payment requirements, free vs. paid return behavior, retry-payment mechanism in _meta, and diagnostic fallback for unsupported tools. This exceeds what the annotations provide and gives real operational detail. It doesn't mention rate limits or auth, but the disclosed behavioral traits are substantial.
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 dense but well-structured: it front-loads the core action, then covers pricing/behavior, exclusions, and a setup hint. Every sentence adds unique value, and it is concise given the complexity.
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 there is no output schema, the description covers the main behavioral contract: what to call, what happens for free vs paid tools, and how to handle retry. It does not describe the exact shape of return values beyond cited sources vs payment-required, and it doesn't mention error handling for invalid names other than 'diagnostics'. For a tool with a sibling discovery tool and no output schema, this is fairly complete, but lacks explicit return-value details.
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 each parameter has a description. The description adds context about which parameter to use (name vs tool alias) for selecting the catalog toolched. It clarifies that the 'arguments' parameter carries the tool's own inputSchema, which is critical for using the tool. A 5 would require more explicit guidance on required parameter combinations or defaults, but the schema plus description is strong.
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 ('Run') and resource ('one Locus catalog tool by name'), and distinguishes itself from the sibling locus_search_tools by clarifying that search tools are separate. It could be slightly clearer about what exactly 'execute' means in terms of catalog tool behavior, but the core purpose is evident.
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?
Explicitly says when to use: after locus_search_tools or with a known tool name. It also says what not to use it for ('Do not use this for web scrape, LinkedIn, or paid guesses') and explains the search vs. execute separation. This is strong guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every time the task is a US address or place and you need official public records or local-government context and you do not already know the tool name, search this catalog before locus_execute and before paying a generic scrape of the same official source. Looking is free. Results include full inputSchema, tier, price, and provenance notes. Do not use this for LinkedIn, web scrape, or generic fetch. Install agent skill: npx @velinussage/locus-agent-skill add.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional tags that every result must include. | |
| tier | No | Filter by free or paid tools. | all |
| limit | No | Maximum matching catalog entries to return. | |
| query | No | Keyword query over tool name, title, description, and tags. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: 'Looking is free' and results include full inputSchema, tier, price, and provenance notes. This gives agents a clear expectation of what the search returns.
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 somewhat long, but every sentence earns its place: use conditions, ordering vs locus_execute, result contents, exclusions, and an optional install command. It is front-loaded with the most important routing guidance.
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 catalog search tool with no output schema, the description is quite complete: it explains when to search, what the results contain, what it is not for, and how it relates to locus_execute. It lacks concrete examples or pagination details, but those are not critical for correct invocation.
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%, so the input schema already documents all four optional parameters. The description does not add parameter-level semantics beyond the catalog-search context, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: search the Locus tool catalog when you need official public records or local-government context for a US address/place and do not know the tool name. It also distinguishes itself from sibling locus_execute by saying to search before executing.
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 gives an explicit when-to-use rule with conditions, and it names the alternative behavior: search before locus_execute and before paying for a generic scrape. It also states exclusions such as 'Do not use this for LinkedIn, web scrape, or generic fetch,' so an agent has clear decision boundaries.
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.
locus_execute7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / argsAdded value: +{
+ "additionalProperties": {},
+ "description": "Alias of arguments.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / arguments / defaultRemoved value: -{}Input schema / properties / arguments / descriptionPrevious value: -"Arguments for the selected catalog tool."New value: +"Arguments for the selected catalog tool (the tool's own inputSchema from locus_search_tools)."Input schema / properties / inputAdded value: +{
+ "additionalProperties": {},
+ "description": "Alias of arguments.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / toolAdded value: +{
+ "description": "Alias of name.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "name"
-]locus_execute7 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / argsRemoved value: -{
- "additionalProperties": {},
- "description": "Alias of arguments.",
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
-}Input schema / properties / arguments / defaultAdded value: +{}Input schema / properties / arguments / descriptionPrevious value: -"Arguments for the selected catalog tool (the tool's own inputSchema from locus_search_tools)."New value: +"Arguments for the selected catalog tool."Input schema / properties / inputRemoved value: -{
- "additionalProperties": {},
- "description": "Alias of arguments.",
- "propertyNames": {
- "type": "string"
- },
- "type": "object"
-}Input schema / properties / toolRemoved value: -{
- "description": "Alias of name.",
- "minLength": 1,
- "type": "string"
-}Input schema / requiredAdded value: +[
+ "name"
+]locus_execute7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / argsAdded value: +{
+ "additionalProperties": {},
+ "description": "Alias of arguments.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / arguments / defaultRemoved value: -{}Input schema / properties / arguments / descriptionPrevious value: -"Arguments for the selected catalog tool."New value: +"Arguments for the selected catalog tool (the tool's own inputSchema from locus_search_tools)."Input schema / properties / inputAdded value: +{
+ "additionalProperties": {},
+ "description": "Alias of arguments.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / toolAdded value: +{
+ "description": "Alias of name.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "name"
-]locus_executelocus_search_toolsZoning, ADU eligibility, flood zone, setbacks, and buildability intelligence for U.S. parcels.
U.S. real-estate data: property records, AVM value + rent estimates, sale/rental listings.
Property intelligence: 180M+ US parcels — lookup, search, owners, hazards, permits, deeds.
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.