Read-only access to Compensation Professional's compensation-focused book library, query-shaped...
Scored across 6 tools
Most tools target clearly distinct resources: answers (get_answer), library works (get_library_work, search_library), feeds (list_...), and wages. The only overlap is between check_wage_locations and get_wage_jurisdiction, both returning minimum-wage rates; they are distinguished by bulk-by-place-name vs single-jurisdiction-by-slug, but an agent could still reasonably pick the wrong one.
The set follows a consistent verb_noun pattern (get_answer, get_library_work, get_wage_jurisdiction, search_library, check_wage_locations). The outlier is list_compensationprofessional_feeds, whose embedded long proper noun breaks the otherwise clean, predictable style.
Six tools is a reasonable, well-scoped set for a read-only reference service spanning answers, library, and wage data. It skews slightly thin, with single-purpose lookups that leave little room for browsing operations.
Wage coverage is solid (bulk location check plus single-jurisdiction lookup) and library works have both search and get. However, answers are only retrievable via a known slug with no list/search_answers tool, and there is no way to enumerate jurisdictions or library works beyond search, creating dead ends for discovery.
Checks the binding minimum-wage rate for up to 50 US locations in one call (city/county rate when it applies, else state, else federal). Each location may be a place name ("Spokane, WA", "Texas", "TX") or a jurisdiction slug. A city with no rule of its own on file returns its state's rate with noLocalRule:true. An unmatched location returns found:false with a reason instead of being omitted. 113 known jurisdictions, e.g.: federal, alaska, alabama, arkansas.
| Name | Required | Description | Default |
|---|---|---|---|
| locations | Yes | Up to 50 places, one per item: "City, ST", a state name or code, or a slug (e.g. Spokane, WA; texas; seattle-wa). | |
| rangeMinimum | No | Optional proposed hourly range minimum; each found row returns belowRangeMinimum (CP-129/130). |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| source | Yes | |
| results | Yes | |
| contract | Yes | |
| requested | Yes | |
| retrievedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, non-destructive, closed-world profile, so the bar is lower; the description still adds substantial behavioral detail beyond them: fallback precedence, the noLocalRule:true signal for cities without their own rule, and the fact that unmatched locations return found:false with a reason rather than being silently dropped. That is exactly the edge-case disclosure an agent needs to interpret partial results.
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 scope and precedence constraint are front-loaded in the first sentence, with the format guidance, edge-case behavior, and jurisdiction examples following in a tight sequence. No sentence is filler; each adds a distinct fact an agent would otherwise have to guess.
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?
An output schema exists, so return shapes need not be spelled out, yet the description still explains the two outcome flags that determine how an agent reads the response. Combined with accepted input formats and the batch limit, nothing needed to invoke this tool 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 coverage is 100%, so the baseline would be 3, but the description adds real meaning by enumerating the accepted location forms ("Spokane, WA", "Texas", "TX") and jurisdiction slugs, which the schema only partially conveys. The second parameter, rangeMinimum, is left entirely to the schema, keeping this from a 5.
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 verb and resource (checks the binding minimum-wage rate) and a precise scope (up to 50 US locations in one call), plus the resolution precedence it applies. This is clearly distinguishable from siblings like get_wage_jurisdiction, which presumably handles a single jurisdiction.
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 makes the batch use case explicit ('up to 50 US locations in one call') and explains the city/county → state → federal resolution order, which tells an agent when a location will resolve to a broader rate. It does not explicitly name or exclude alternatives such as get_wage_jurisdiction, so the routing guidance stops just short of full when/when-not framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one authored /answers page as structured content: question, short answer, problem frame, and citations. Known slugs (14): how-to-set-pay-ranges, what-should-we-pay-for-a-role, is-our-pay-competitive, how-to-tie-executive-pay-to-performance, executive-compensation-components, how-much-executive-pay-at-risk, business-case-for-changing-rewards, make-financial-case-for-compensation, ….
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Answer slug from the query map (e.g. how-to-set-pay-ranges). |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| sources | Yes | |
| contract | Yes | |
| question | Yes | |
| citations | Yes | |
| shortAnswer | Yes | |
| canonicalUrl | Yes | |
| problemFrame | Yes | |
| categoryTerms | Yes | |
| contentTargets | Yes | |
| relatedQuestions | Yes |
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 by structured data. The description usefully states the shape of the returned content but says nothing about error behavior for invalid slugs, which is the main remaining behavioral gap.
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?
Front-loaded with what the tool returns, followed by the slug list. Efficient overall, though the slug enumeration is truncated with an ellipsis and eats a fair share of the text without covering all 14.
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?
An output schema exists, so return-value detail is not required, and the description adequately covers the purpose, content shape, and valid inputs. Only the handling of unknown slugs or the meaning of 'query map' remains unstated.
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 slug parameter is self-documenting, but the description goes beyond the schema by enumerating known slugs (how-to-set-pay-ranges, is-our-pay-competitive, etc.), which gives the agent concrete valid values the schema itself cannot express.
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 (returns) and resource (one authored /answers page) and enumerates the structured fields returned: question, short answer, problem frame, citations. No sibling tool does anything comparable, so the agent can distinguish it immediately.
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 mention of 'Known slugs' plus the example list implies the tool is for fetching a known authored answer page, but there is no explicit statement of when to use this versus sibling tools like search_library or get_library_work, nor any guidance on what happens with an unknown slug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one compensation library work's bibliographic record and (when profiled) its thesis.
| Name | Required | Description | Default |
|---|---|---|---|
| libraryId | Yes | Library catalog id (e.g. lib933f3afbe567c9ab). |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| year | Yes | |
| pitch | Yes | |
| title | Yes | |
| author | Yes | |
| logline | Yes | |
| contract | Yes | |
| libraryId | Yes | |
| canonicalUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only and non-destructive. The description adds meaningful behavioral context: it returns a single record, and the thesis is included only 'when profiled,' which helps set expectations for conditional output. 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?
One sentence that conveys the core behavior and the conditional thesis inclusion without unnecessary detail. It is front-loaded, scannable, and appropriately sized for this simple tool.
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 one parameter, full schema coverage, safe-read annotations, and an output schema present, the description is nearly complete. The only slight gap is that 'when profiled' is not elaborated, but the output schema likely clarifies the shape, so this is acceptable.
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 schema covers the only parameter fully with a clear description and example. The tool description does not add further parameter meaning, but the baseline of 3 applies because schema coverage is 100%.
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 verb ('Returns') and resource ('one compensation library work's bibliographic record'), and notes the conditional thesis inclusion. This distinguishes it from search_library, which is for finding works rather than retrieving a single record by ID.
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: call this when you need a single library work's bibliographic record by its library ID. However, it does not explicitly mention when to prefer this over siblings such as search_library or 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.
Returns one tracked jurisdiction's current minimum-wage rate, effective date, validation status, and next scheduled step. 113 known jurisdictions, e.g.: federal, alaska, alabama, arkansas.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Jurisdiction slug (e.g. federal, california). |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| rate | Yes | |
| slug | Yes | |
| type | Yes | |
| source | Yes | |
| contract | Yes | |
| currency | Yes | |
| fullLabel | Yes | |
| stateCode | Yes | |
| typeLabel | Yes | |
| confidence | Yes | |
| displayName | Yes | |
| retrievedAt | Yes | |
| canonicalUrl | Yes | |
| scheduledRule | Yes | |
| classification | Yes | |
| effectiveStart | Yes | |
| validationStatus | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only behavior is established. The description adds useful context by stating the tool returns exactly one jurisdiction's record and that there are 113 known jurisdictions, but it does not disclose additional behavioral caveats such as error behavior or lookups for unknown slugs.
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, front-loads the essential return contents, and then provides useful scoping examples. There is no filler or repetition of the tool name or 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?
This is a simple one-parameter read tool with output schema available and safe annotations. The description covers what the tool returns, its single-input semantics, and the known slug space, so nothing critical is missing for an agent to select and invoke it correctly.
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 schema already documents the 'slug' parameter with 100% coverage, so the baseline is 3. The description adds meaningful value by providing multiple concrete slug examples (federal, alaska, alabama, arkansas) and confirming a bounded set of 113 jurisdictions, which helps the agent infer valid slug format.
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 verb ('Returns') and a specific resource: one tracked jurisdiction's current minimum-wage record, including rate, effective date, validation status, and next scheduled step. It also gives the scope (113 known jurisdictions) and concrete examples, making it easy to distinguish from the unrelated 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 implies the tool's use case clearly: call it when you need the current minimum-wage details for a single jurisdiction identified by slug. It does not explicitly state when not to use it or name alternatives, but the sibling tools are unrelated, so no exclusion is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Compensation Professional's free machine-readable feeds and their MCP/REST availability. OpenAPI is also published at https://compensationprofessional.com/openapi.json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| feeds | Yes | |
| openapi | Yes | |
| contract | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and destructiveHint=false, and the description adds that the feeds are free, machine-readable, and exposes an OpenAPI document URL. It does not describe pagination, rate limits, or output detail, but for a zero-parameter listing endpoint with an output schema this is acceptable.
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 concise sentences; the first front-loads the action and resource, and the second adds a useful OpenAPI reference without redundancy. Every sentence 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 no-parameter, read-only listing tool with an output schema and annotations, the description is complete. It states what is listed, how availability is described, and links to the API documentation for further detail.
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?
There are no parameters, so the schema is fully covered and the baseline for zero-parameter tools applies. The description does not need to explain parameter meaning because none exist; the only context provided is the resource being listed.
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 uses a specific verb ('List') and names the exact resource ('Compensation Professional's free machine-readable feeds') and what information is provided (MCP/REST availability). This clearly separates it from sibling retrieval/search tools because it enumerates available feeds rather than answering or 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 description implies the appropriate use case: when an agent needs to discover available machine-readable feeds and how they can be accessed via MCP/REST. It gives clear context but does not explicitly name sibling alternatives or state 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.
Search or list the compensation-focused book library by title/author substring and/or classifier tag. No filters returns the first page.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Case-insensitive classifier-tag substring. | |
| limit | No | Max rows to return (default 25, max 100). | |
| query | No | Case-insensitive title/author substring. |
| Name | Required | Description |
|---|---|---|
| tag | Yes | |
| count | Yes | |
| query | Yes | |
| total | Yes | |
| results | Yes | |
| contract | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral detail beyond the annotations, namely that omitting filters returns the first page, which helps set caller expectations for the default result set.
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 convey the core purpose, the filtering dimensions, and the no-filter behavior with no wasted words. The most important information 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.
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 three optional, fully documented parameters and an output schema present, the description covers the core usage and the important no-filter case. The only minor gap is that pagination behavior beyond 'first page' is not explained, but the output schema and annotations carry much of the remaining context.
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 descriptions cover 100% of parameters, so the baseline is 3. The description mostly reinforces what the schema already says ('title/author substring', 'classifier tag') and adds minor semantic value by noting filters can be combined with 'and/or', but it does not substantially extend parameter understanding.
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 action ('Search or list'), identifies the resource ('compensation-focused book library'), and names the search dimensions (title/author substring and classifier tag). This clearly distinguishes it from sibling tools like get_library_work or get_answer.
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 when to use the tool: when searching or listing library contents by title, author, or tag, and it clarifies that no filters returns the first page. However, it does not explicitly compare against sibling tools or state when not to use it, leaving some inference to the agent.
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.
check_wage_locations7 fields changedInput schema / properties / locations / descriptionPrevious value: -"Up to 50 jurisdiction slugs (e.g. seattle-wa, denver-co, texas)."New value: +"Up to 50 places, one per item: \"City, ST\", a state name or code, or a slug (e.g. Spokane, WA; texas; seattle-wa)."Input schema / properties / rangeMinimumAdded value: +{
+ "description": "Optional proposed hourly range minimum; each found row returns belowRangeMinimum (CP-129/130).",
+ "exclusiveMinimum": 0,
+ "type": "number"
+}Output schema / properties / results / items / properties / belowRangeMinimumAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "next": {
+ "type": "boolean"
+ },
+ "nextEffective": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "now": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "now",
+ "next",
+ "nextEffective"
+ ],
+ "type": "object"
+}Output schema / properties / results / items / properties / candidatesAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / results / items / properties / didYouMeanAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / noLocalRuleAdded value: +{
+ "type": "boolean"
+}Output schema / properties / results / items / properties / reasonAdded value: +{
+ "enum": [
+ "not_recognised",
+ "ambiguous"
+ ],
+ "type": "string"
+}check_wage_locationsget_membership_offerget_membership_offerlist_compensationprofessional_feeds1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "contract": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ },
+ "feeds": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "auth": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "mcpTool": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "method": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "rest": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "method",
+ "path",
+ "summary",
+ "mcpTool",
+ "rest",
+ "auth"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "openapi": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "contract",
+ "count",
+ "openapi",
+ "feeds"
+ ],
+ "type": "object"
+}get_answerget_library_workget_wage_jurisdictionlist_compensationprofessional_feedssearch_libraryRead-only access to The Family Almanac's parenting-focused book library, grounded guide metadata...
Read-only access to Penwright's writing-craft book library, grounded guide metadata (card-level...
Read-only EngineerPro engineering library (118 book profiles) and software-engineering tools.
Read-only MCP access to Vela's corpus of human experience: cited passages, coordinates, reading path
Add one secure layer between your agents and this server.