ICF MCP Server

by stayce

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool has a uniquely defined purpose: lookup, search, validate, navigate hierarchy (children, parent, siblings, chain), explain qualifiers, parse qualified codes, browse categories, build profiles, and instrument management (list, details, mapping, scoring, suggestion). No two tools overlap in functionality, enabling agents to select the correct tool unambiguously.
Naming Consistency4/5
All tools share the 'icf_' prefix and most follow a verb_noun pattern (e.g., 'icf_browse_category', 'icf_get_children', 'icf_search'). However, 'icf_instrument_details' and 'icf_instrument_icf_mapping' are noun phrases, and 'icf_overview' is just a noun, breaking the pattern. Minor inconsistency in a largely consistent set.
Tool Count5/5
With 17 tools, the server covers all essential ICF operations—navigation, search, validation, qualifier handling, and instrument management—without being excessive. Each tool serves a distinct need, and the count feels appropriate for the domain's complexity.
Completeness5/5
The tool surface is comprehensive for an ICF classification server: it includes lookup, search, validation, full hierarchy navigation (children, parent, siblings, chain), qualifier explanation and parsing, profile building, and instrument-related operations (listing, details, mapping, scoring, suggestion). No obvious gaps exist for typical use cases.
Average 4.1/5 across 17 of 17 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on July 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the return type but does not disclose behavioral traits like read-only nature, performance, or side effects. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: a one-line summary, followed by examples, then an Args list. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existence of an output schema (though not shown), the return description is adequate. However, it does not detail the structure of the suggested instruments or rationale beyond a high-level statement. Sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description lists all parameters with examples and semantics (e.g., 'icf_code: ICF code to match against instrument mappings'). However, it does not specify format constraints or that at least one parameter is needed. Partially compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool suggests assessment instruments for a condition, ICF code, or domain. It provides examples and distinguishes from sibling tools like icf_list_instruments by focusing on suggestion rather than listing all instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use (when searching instruments by condition, ICF code, domain) but lacks explicit guidance on when not to use or alternatives. No mention of sibling tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It states the tool creates a structured summary, but it does not disclose whether codes are validated, what happens with invalid or missing codes, or any rate limits or side effects. For a tool that processes input, more transparency on error handling and processing guarantees is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs and a clear Args/Returns section. The first sentence immediately communicates the tool's purpose, front-loading key information. Every sentence adds value without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one required parameter and an existing output schema (though not shown), the description is mostly complete. It explains the input and output nature. However, the lack of behavioral transparency (e.g., error handling) slightly reduces completeness. The description adequately covers the tool's purpose for a simple build operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'codes' has 0% schema description coverage. The description adds meaning by stating 'List of ICF codes (e.g., ["b280", "d450", "e120"])', clarifying it expects an array of code strings. This goes beyond the raw schema but does not specify the exact format or constraints (e.g., valid code prefixes, case sensitivity). Examples help but are not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Build an ICF functional profile from multiple codes' and elaborates with 'Creates a structured summary organizing multiple ICF codes by component'. This is a specific verb and resource, and it distinguishes from sibling tools like icf_lookup or icf_search, which focus on querying or navigating codes rather than assembling a profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is 'useful for documenting a person's functional status across body functions, structures, activities, and environmental factors', implying a use case. However, it does not specify when not to use it or provide explicit alternatives among the 16 sibling tools, such as suggesting icf_lookup for single code details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions returning a list with titles and relevance scores, which is useful. However, it does not disclose any side effects, authentication needs, or rate limits. The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief header, usage examples, and clearly labeled Args and Returns sections. It is concise without being overly terse, though the examples could be shortened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema exists), the description covers the essential information: what the tool does, how to use it, and what it returns. No major gaps are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so all parameter meaning comes from the description. It explains 'query' as search terms with examples and 'max_results' as maximum results with default 10. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the ICF classification by keywords or description. Examples like 'walking' and 'pain' make the purpose concrete. However, it does not explicitly differentiate from sibling tools like icf_browse_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool when you know the functional area but not the specific code, providing implicit context. However, it lacks explicit guidance on when not to use it or how it differs from alternatives like icf_lookup or icf_browse_category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It explains the return type ('parent code details and the relationship') and gives examples. However, it doesn't disclose edge cases like when the code is a root category or invalid input. For a simple query tool, the transparency is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three paragraphs: a one-sentence purpose, a brief explanation with examples, and a structured list of args and returns. Every sentence adds value without redundancy. It is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown), so the description need not detail return values fully. It mentions 'parent code details and the relationship,' which is sufficient. However, it lacks information on error handling, behavior for codes at the top of the hierarchy, or prerequisites. Given the tool's simplicity, it is marginally complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, 'code', and the schema description coverage is 0%. The description adds value by explaining the purpose ('ICF code to find the parent of') and providing concrete examples ('e.g., "d450", "b2801"'). This goes beyond the bare schema definition of a string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get the parent category of an ICF code to navigate up the hierarchy.' It uses a specific verb and resource, making the purpose immediately clear. While it doesn't explicitly differentiate from siblings, the examples and mention of hierarchy set it apart from tools like icf_get_children.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance: 'Use this to move from a specific code up to its broader category.' Examples illustrate the hierarchical movement. It doesn't mention when not to use it or alternatives, but the context is clear enough for the agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a safe read operation but doesn't disclose any behavioral traits beyond returning general information. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two short sentences. Every word is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple purpose, the description is complete. The presence of an output schema means return values don't need elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no parameter info, which is acceptable since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get an overview of the ICF classification system', which is a specific verb+resource. It distinguishes itself from siblings that deal with specific categories, qualifiers, children, lookup, or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With five sibling tools, explicit context would help agents decide when to choose overview over more specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It states the tool returns a list of child codes, which is the basic behavior. However, it does not disclose error handling (e.g., invalid code), case sensitivity, or any side effects. This is adequate for a simple lookup but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence states purpose, followed by hierarchical examples, usage guidance, and explicit Args/Returns. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, clear hierarchy) and presence of an output schema, the description covers purpose, parameter, and return. It is nearly complete but missing notes on edge cases (e.g., empty results) or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'code' parameter (0% coverage). The description adds meaning by specifying 'Parent ICF code to get children for', clarifying the parameter's role. This compensates for the schema gap effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves child codes (subcategories) of an ICF code, using specific verbs and resources. The examples of hierarchy ('d4 (Mobility) contains d410-d499') further clarify purpose, and the distinction from siblings like 'icf_browse_category' is implicit due to the narrow focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use ('drill down into more specific codes') but lacks explicit guidance on when not to use or alternatives. While sibling tools exist (e.g., 'icf_browse_category'), no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. Lists output content but omits behavioral traits like auth needs, side effects, or performance. Implies read-only but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences for purpose, followed by Args and Returns. Front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key output aspects and parameter usage. Output schema exists, so return value details are managed. Slight gap in explaining format or example response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage 0%, but description adds examples ('GAD-7', 'PHQ-9') and format ('Instrument name or abbreviation'), compensating well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get full details of a clinical assessment instrument' and enumerates specific content types (questionnaire items, scoring, ICF mappings). Distinguishes from siblings like icf_list_instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when instrument details are needed, but lacks explicit when-to-use vs alternatives. No guidance on when not to use, especially given large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the return includes definition, inclusions, and exclusions, and implies read-only behavior. However, it omits error handling (e.g., invalid codes) and case sensitivity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then provides necessary background in a structured manner (prefixes, args, returns). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, output schema exists), the description is mostly complete. It provides ICF context but lacks details like error behavior. Still, it covers the essential use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but the description adds meaning by providing code prefix categories and examples ('b280', 'd450'), clarifying the expected format and valid values beyond type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Look up an ICF code and get its full details', providing a specific verb+resource combination that distinguishes it from sibling tools like icf_search, icf_get_children, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have a specific code) but provides no explicit when-to-use or when-not-to-use guidance, nor alternatives. The prefix explanation adds background but not decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns total score, severity level, ICF qualifier mapping, and clinical guidance. It also explains inputs with an example. However, it does not address edge cases such as invalid instrument names, mismatched response lengths, or error behavior, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with the main purpose in the first line, then provides clear parameter details with examples, and concludes with a summary of returns. Every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and an output schema exists, the description covers the key aspects: input format with examples, and output components (total score, severity, mapping, guidance). It could be more complete by noting validation requirements (e.g., response count must match instrument items), but the information provided is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so effectively by explaining the 'name' parameter as 'Instrument name or abbreviation (e.g., 'GAD-7', 'PHQ-9', 'SLEDAI')' and the 'responses' parameter as 'List of response values, one per item in order (e.g., [1, 2, 1, 0, 1, 2, 1] for GAD-7).' This adds crucial meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Score a completed assessment instrument and get clinical interpretation.' It specifies the verb 'score', the resource 'completed assessment instrument', and the outcome. This distinguishes it from sibling tools like icf_browse_category or icf_build_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a completed instrument by instructing to 'Pass the instrument name and a list of integer responses.' However, it does not explicitly state when to use this tool versus alternatives, nor does it mention conditions to avoid using it. Usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains the tool takes an ICF code and returns a list of sibling codes with titles. However, it does not mention error handling (e.g., invalid code), rate limits, or other behavioral details, but for a simple query tool this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose statement, a one-line usage hint, and an example with Args/Returns structure. Every sentence adds value and no information is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no annotations), the description adequately covers what the tool does, how to use it, and what it returns. The presence of an output schema (indicated by context) supplements the return description. It does not discuss edge cases but is complete for a straightforward lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds an example (e.g., 'd450', 'b280') and explains the parameter as 'ICF code to find siblings for,' which provides meaning beyond the schema's type and title alone. It could further specify format or validity constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get sibling codes — other codes at the same level sharing the same parent,' providing a specific verb and resource. It distinguishes from sibling tools like icf_get_children and icf_get_parent by focusing on codes at the same level, and includes an example with d450 and its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Useful for finding related or alternative codes,' which gives clear usage context. It provides an example but does not explicitly state when not to use or directly compare to all sibling tools, though the tool name and context of sibling tools imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It explains the parsing behavior and output format with examples, but does not mention error handling for invalid codes or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (~10 lines) with examples upfront, followed by clear Args and Returns sections. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the input format, purpose, and return type. The examples clarify different ICF categories and qualifier patterns, making it complete for the use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides multiple examples of valid code patterns (with dots, plus) and explains qualifier structure, adding significant meaning beyond the bare schema property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses and explains qualifier components of an ICF code, with distinct verb 'parse' and resource 'qualified ICF code'. Examples differentiate from siblings like icf_explain_qualifier (single qualifier) and icf_validate_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., icf_explain_qualifier). Usage is implied only through examples; no when-not or alternative indicators are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: format validation, qualifier breakdown, and API verification. It mentions return structure, providing adequate transparency for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a clear purpose, examples, and parameter description. It is front-loaded and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and presence of an output schema, the description covers input examples and return type. It could mention error handling but is otherwise complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'code' has no schema description (0% coverage). The description adds valuable context: examples of valid codes (base and qualified), explaining what format is expected, which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates an ICF code, checking format, qualifiers, and existence. It provides specific examples of base and qualified codes, distinguishing it from sibling tools like icf_parse_qualified_code or icf_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for validation but does not explicitly state when to use versus alternatives. Context suggests it for verifying code validity, but no exclusions or sibling comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately describes a read-only list operation returning 'Table of available instruments with key details', implying no side effects. It could explicitly state non-destructiveness, but the verb 'list' sufficiently indicates safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus Args/Returns section. It is front-loaded with the purpose, and every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only 1 optional parameter and simple behavior, the description covers purpose, parameter meaning, and return value. An output schema exists, so detailed return structure is not needed. The description is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides type and default for 'domain'. The description adds valuable context: example values ('Mental Health', 'Rheumatology', etc.) and explains that leaving it empty returns all instruments, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'standardized assessment instruments', and provides specific examples (GAD-7, PHQ-9, etc.), distinguishing it from sibling tools like icf_instrument_details or icf_suggest_instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (list all instruments or filter by domain) but does not explicitly mention when NOT to use it or suggest alternatives like icf_instrument_details for detailed info on a specific instrument.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the output as a complete classification chain with an example format. It does not disclose error handling or authorization needs, but adequately explains the read-only behavior and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus structured Args and Returns. It is front-loaded with the purpose, includes an illustrative example, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers what it does, how to use it, and what it returns with an example. It is fully adequate given the complexity and available structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'code'. The description adds meaning by specifying it as an 'ICF code to trace' and providing examples ('b2801', 'd4501'). This compensates for the schema gap, though format constraints could be clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the full hierarchical path from the ICF root to a specific code. It uses a specific verb and resource, distinguishes from siblings like icf_get_parent and icf_get_children, and provides an example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is 'useful for understanding where a code sits in the overall ICF structure,' providing clear context for use. It does not explicitly state when not to use it or mention alternatives, but the context and sibling tools imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It indicates a read-only operation ('show', 'displays') and describes the output structure. No contradictions or missing behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences plus Args/Returns. Every sentence adds value, with the purpose stated first. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description plus schema fully cover the necessary information. It explains input and output sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context to the 'name' parameter with examples ('GAD-7', 'SLEDAI', 'WHODAS') and explains it accepts instrument names or abbreviations. Schema coverage is 0%, but description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show how an assessment instrument maps to ICF codes.' and details the output organized by relationship type. This distinguishes it from siblings like icf_instrument_details (instrument metadata) and icf_list_instruments (list all instruments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to see ICF mappings for a specific instrument. However, it does not explicitly state when not to use or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the return is an 'Overview of the category/sub-chapter with child codes', which is transparent about the output. It does not discuss error handling or performance, but the behavior is clear for a read-only browse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose sentence, a list of accepted inputs, and a brief return statement. Each line adds value with no unnecessary repetition, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter and the presence of an output schema (not shown but indicated), the description covers all necessary contextual information: what to input, what format, and what to expect. It is complete for a straightforward browse tool without needing to detail return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description fully explains the single parameter 'category' with specific examples and formats (component letter or sub-chapter code). This adds significant meaning beyond the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'browse' and the resource 'ICF category or sub-chapter', with explicit examples of accepted codes. It distinguishes from sibling tools like icf_get_children or icf_search by focusing on browsing an overview rather than retrieving specific details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear examples of valid inputs (top-level components and sub-chapter codes), which implies when to use this tool. However, it does not explicitly mention when not to use it or compare to alternatives like icf_get_children for code details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains behavior: returns an explanation based on component and optional qualifier. It notes that omitting qualifier shows all qualifiers. No side effects are expected for a read-only info tool. It does not specify error handling for invalid inputs, but transparency is adequate given the simple nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states purpose, followed by a clear list of qualifier types per component. No redundant or unnecessary sentences. Every line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, no required, output schema exists), the description is complete. It covers all necessary details: what the tool does, the components, qualifier behavior, and return value. An agent can correctly select and invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It thoroughly explains both parameters: component with explicit values ('generic','b','s','d','e') and their meaning, and qualifier as optional with behavior 'shows all qualifiers' vs 'explains specific value'. This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Explain ICF qualifier systems.' It specifies the resource (ICF qualifier systems) and the action (explain). The qualifier types per component are listed, distinguishing it from sibling tools like icf_lookup or icf_parse_qualified_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's use: explaining qualifier systems per component. It implicitly guides when to use it (when understanding the qualifier structure is needed) but does not explicitly mention when not to use it or recommend alternatives. The context from sibling tools makes the distinction clear, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![icf-mcp-server MCP server](https://glama.ai/mcp/servers/stayce/icf-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/stayce/icf-mcp-server)

Score Badge

Copy to your README.md:

[![icf-mcp-server MCP server](https://glama.ai/mcp/servers/stayce/icf-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/stayce/icf-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stayce/icf-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server