kyb-mcp

by iGitScor

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: registry lookup (search, get, find, bulk) is clearly separated from dossier workflow (create, list, get, note, status, archive, draft). No two tools overlap meaningfully, and the descriptions reinforce the boundaries.
Naming Consistency4/5
Names are uniformly snake_case and mostly follow a verb_noun pattern (get_company, create_dossier, list_dossiers, archive_dossier). Minor deviations like find_by_person and bulk_check are still predictable and do not harm usability.
Tool Count5/5
11 tools is well-scoped for a KYB server: registry research and dossier management each get enough coverage without redundancy. Every tool serves a clear step in the workflow.
Completeness4/5
The toolset covers the core KYB lifecycle: company research, dossier creation, note-taking, status progression, and archival. Minor gaps such as no delete/unarchive or document attachment are workable for the apparent domain.
Average 3.8/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful behavioral detail: the SIREN is verified against the registry first, implying an error path if it does not exist. However, it does not disclose whether opening creates a new dossier, what happens if one already exists, or what side effect the optional note has, and the annotations are all false and provide little coverage.
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 short sentences: the first states the action and resource, the second adds a meaningful precondition. There is no filler or redundant repetition of the schema.
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 small parameter set, full schema coverage, and presence of an output schema, the description is minimally usable. However, it leaves the state-change semantics and sibling-tool routing underspecified, so it is not fully complete for an agent operating without extra context.
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 description coverage is 100%, so the schema already documents both parameters. The description only reinforces the role of siren via the registry verification and adds no new semantics for the note parameter.
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 ('Open') and resource ('a KYB dossier for a company'), and adds a concrete verification step. It is distinguishable from siblings by name and wording, though it does not explicitly contrast itself with tools like get_dossier or list_dossiers.
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 is given about when to use this tool versus its siblings. It does not mention that get_dossier should be used to read an existing dossier or that search_companies might be needed to find a SIREN first; the only implied context is the registry-existence check.
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?
Annotations already declare readOnlyHint=false and idempotentHint=true, covering the mutation and retry-safety profile. The description adds useful workflow context beyond the annotations, but it does not disclose behavioral details like allowed transitions, whether any status change can be undone, or what side effects occur beyond the status update. No contradiction with annotations exists.
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 a single, front-loaded sentence with no filler or redundancy. It is concise and immediately communicates the tool's role, though it is slightly minimal and could carry a bit more guidance without becoming verbose.
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 schema covers all parameters, includes an enum for status, and an output schema exists, so the call shape is well defined. What is missing is explicit guidance about when this tool is appropriate versus archive_dossier and what workflow constraints apply. For a simple status-transition tool, the description is adequate but not rich.
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 description coverage is 100%, so the schema already documents dossier_id, status, and reason. The description itself adds no parameter-level meaning beyond framing the action as a workflow move, which is sufficient given the full schema coverage. Baseline 3 is appropriate.
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 states a specific action ('Move a dossier') and a clear resource/domain ('review workflow'), so an agent understands this updates a dossier's status. It does not explicitly enumerate the statuses or fully distinguish itself from archive_dossier, but the workflow framing makes the core purpose clear.
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 phrase 'through the review workflow' implies this tool is for status transitions such as open, in_review, approved, or rejected. However, there is no explicit 'use when' or 'do not use for archiving' guidance in the description; the archive_dossier exclusion only appears in the schema's status parameter description, not in the tool description.
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?
The description adds a behavioral trait beyond the annotations: the result includes 'all its notes.' The readOnlyHint already covers safety, so the added note-scope detail is useful context. However, it does not disclose any potential edge cases or return characteristics beyond that single trait.
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 five words with no filler, and the key differentiator ('with all its notes') is front-loaded. It is terse but earns its place by adding scope information beyond the tool's name. It could be slightly more explicit, but it is appropriately concise.
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?
For a single-parameter getter with a complete input schema, a readOnly annotation, and an output schema, the minimal description is largely sufficient. It does not explain the return format, but that is covered by the output schema. The only missing element is explicit comparison with list_dossiers, which is more of a usage-guidance concern.
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 description says nothing about the dossier_id parameter, but the input schema provides 100% coverage with a clear title, description, and an example value. Since the schema fully documents the only parameter, the baseline of 3 applies.
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 identifies the resource—a single dossier—and adds a distinguishing detail: it includes all notes. This separates it from list_dossiers (plural) and from sibling tools targeting other entities like get_company. It relies on the title for the verb 'Get' and doesn't mention lookup by ID, but the resource and scope are clear.
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?
No explicit usage guidance is provided. The singular wording implies this tool is for fetching one specific dossier, contrasting with list_dossiers, but it does not state when to prefer it or exclude alternatives. There are no direct comparisons or 'use when' instructions.
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?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), so the description does not need to restate those. The word 'Append' adds a useful nuance that the note is added to existing content rather than replacing it, but the description provides no further behavioral context such as response shape or side effects.
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 a single, efficient sentence with no filler or redundant restatement. It front-loads the key action and object, making it easy for an agent to parse quickly.
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?
For a simple two-parameter tool with a complete schema and an output schema, the description is largely adequate. The only noticeable gap is the lack of usage guidance relative to sibling tools, but the low complexity means the core information needed to invoke the tool is present.
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 description coverage is 100%, so the schema already documents both parameters. The description does not add meaningful parameter semantics beyond the schema; it vaguely maps to 'body' being the note content, but no extra detail is provided.
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 uses a specific verb ('Append') and resource ('a dossier'), clearly indicating the tool adds a note to an existing dossier. This distinguishes it from sibling tools like set_status, archive_dossier, or draft_risk_summary, which perform different actions.
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?
The description gives no explicit guidance on when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. Usage is only implied by the tool name and generic action phrase; there is no mention of when a note is appropriate compared to creating a dossier or drafting a risk summary.
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?
Annotations already establish readOnly, idempotent, and open-world behavior, and the description does not contradict them. The description adds minimal behavioral context beyond that, such as the kind of data included, but it does not reveal potential gaps like missing financials or record currency.
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?
One concise sentence with a front-loaded scope and a clear list of record components. There is no redundant wording, and every part of the description contributes to understanding what the tool returns.
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?
For a single-parameter lookup with an output schema and read-only/idempotent annotations, the description is nearly sufficient. The only gap is that it does not explicitly route the agent away from searching when the SIREN is unknown, but the schema and example make the required input clear.
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 input schema fully documents the only parameter, siren, including format and an example. The description adds no extra semantic detail about the parameter, so the baseline of 3 is appropriate since the schema carries the meaning.
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 identifies the resource: a single company's full registry record, with a concrete scope (identity, head office, directors, latest financials). It implies a lookup-by-identifier tool and is distinct from the sibling search_companies, but it does not explicitly contrast itself with those siblings.
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 phrase "for one company" implies this is the right tool when an agent already has a specific company identifier and needs the full record rather than a search. It does not explicitly state when to prefer this over search_companies or find_by_person, so guidance is only implied.
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?
Annotations already mark readOnlyHint=true, so the safe read behavior is covered. The description adds the 'most recently updated first' ordering, which is a behavioral trait not present in structured fields. It does not contradict the annotations and provides useful sorting context.
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 entire description is six words and contains no filler or repeated schema information. It front-loads the only non-obvious behavior (ordering). It is perhaps terse but not wasteful.
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?
For a simple read-only list with one optional parameter, the description plus schema and annotations are nearly sufficient. The description covers ordering, the schema covers the status filter, and annotations cover safety. It does not mention pagination or explicit 'all dossiers' scope, but the output schema and simplicity limit the gap.
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 single optional status parameter is fully documented in the schema with 'Filter by status; omit for all' and an enum of acceptable values. Since schema_description_coverage is 100%, the description does not need to add parameter detail. The tool description adds no additional parameter semantics, so baseline 3 applies.
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 'Dossiers most recently updated first' conveys the result ordering but does not explicitly state an action; the title 'List dossiers' supplies the verb and resource. It distinguishes the tool from get_dossier by plural scope, but not explicitly from listing/searching alternatives. This is clear but not maximally specified.
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?
There is no statement about when to use list_dossiers instead of get_dossier, search_companies, or create_dossier. The ordering information implies a read-only list use, but no exclusions or alternative routing 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?
The annotations already declare readOnly, idempotent, and open-world behavior. The description adds valuable non-obvious behavioral context: matching is by name only, common names return homonyms, and results should be treated as leads rather than proof of identity.
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 brief and front-loaded: purpose first, then matching limitations, then interpretation guidance. Every sentence earns its place without repeating schema defaults or annotation hints.
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 readOnly/idempotent annotations and the presence of an output schema, the description covers the essential semantics: what entities are returned, how matching works, and how to interpret the results. It leaves only_active and pagination details to inference, but those are reasonably self-evident from parameter names and defaults.
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 schema documents last_name and first_names, and the description adds the key nuance that matching is name-only, which affects how those parameters behave. However, it does not explain only_active or page semantics, so with 50% schema coverage it only partially compensates for undocumented parameters.
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 states a specific purpose: find companies where a person is listed as a director or elected official, with French equivalents for precision. This clearly distinguishes it from siblings like search_companies, which presumably search by company rather than by person.
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 intended use case is implied by the title and description, and the homonym caveat tells the agent how to treat results. However, there is no explicit when-to-use versus when-not-to-use guidance or routing to alternatives such as search_companies.
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?
The annotations already declare destructiveHint=true and idempotentHint=true, so the description's main added value is the 'after the user confirms' precondition, which signals that this is a user-gated destructive action. No contradiction with annotations exists.
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?
A single sentence with no filler. It front-loads the action and immediately states the essential precondition, making every word earn its place.
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?
For a one-parameter tool with rich annotations and an output schema, the description is sufficient. It could theoretically elaborate on what 'archiving' changes, but the low complexity, the user-confirmation precondition, and the existing structured metadata make the definition complete enough for correct invocation.
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 description coverage is 100% and the dossier_id parameter is already well documented in the schema with a source ('returned by create_dossier') and an example. The description adds no additional parameter meaning, so the baseline score of 3 applies.
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?
States a specific verb ('Archive') and a specific resource ('a dossier'), and adds a workflow condition ('after the user confirms in their client'). The verb clearly distinguishes it from sibling tools like get_dossier, list_dossiers, and create_dossier.
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?
Provides clear context: the tool should only be used after the user has explicitly confirmed in their client. It does not explicitly name alternatives or state when not to use it, but the precondition is unambiguous and adequate for this simple operation.
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?
The description discloses important behaviors beyond the annotations: it stores an AI note (a side effect), depends on client sampling support, and produces only a draft that should not be treated as a decision. These details meaningfully augment the all-false annotations.
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 compact and front-loaded: the first sentence states the action, the second gives a prerequisite, and the third clarifies the appropriate use. 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?
With one fully documented parameter, an output schema, and a description covering purpose, side effect, prerequisite, and limitation, the tool is nearly complete. It could be slightly stronger by explicitly noting what to do if the client lacks sampling support, but no critical information is missing.
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 description coverage is 100%, and the dossier_id parameter is already well documented with its origin and an example. The tool description adds no additional parameter-specific meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Ask the client's own model for a first-draft risk summary and store it as an AI note.' This clearly distinguishes it from generic sibling tools like add_note or get_dossier by describing a unique AI-assisted workflow.
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 gives clear context and a prerequisite: 'Requires a client that supports sampling,' and frames the output as 'a starting point for the analyst, never a decision.' It does not explicitly name alternatives, but the context is sufficient to guide appropriate use.
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?
Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: progress reporting and respect for the registry rate limit (~5/s). These details go beyond what annotations or schema provide.
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 short sentences with no filler. The core purpose is front-loaded, and the rate-limit note is a worthwhile addition that earns its place.
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 one-parameter bulk lookup with readOnlyHint=true and an output schema, the description covers the essential operational facts: bulk behavior, progress reporting, and rate limiting. Nothing critical is missing.
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 for the single parameter is 100%, so the baseline is 3. The description says 'many SIRENs,' which echoes the schema's array-of-sirens design but adds no new parameter-level meaning.
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 a specific action ('Look up many SIRENs at once') with a defined resource and scope. The 'many at once' phrasing distinguishes it from single-lookup siblings like get_company.
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 conveys when to use the tool: when many SIRENs need to be checked in one operation. It does not explicitly name an alternative for single lookups, but the context is clear enough.
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?
Annotations already cover read-only, idempotent, and open-world behavior, so the description only needs to add operational context. It adds the registry source and the exact summary fields returned (SIREN, status, activity, head office, headcount band). It does not detail pagination behavior or sorting, but that is partially represented by page/per_page in the schema.
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 sentences with no filler: the first states scope and source, the second states return contents and a pointer to the logical next tool. Information is front-loaded and each sentence earns its place.
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 search tool with an output schema, rich annotations, and schema-documented filtering parameters, the description covers the necessary context: what is searched, where, what is returned, and when to switch to get_company. Nothing critical is missing for an agent to select and invoke the tool correctly.
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 description coverage is 71%, and the schema already explains query, naf_code, department, only_active, and postal_code. The description adds no parameter-level meaning beyond the schema, and page/per_page are not explicitly described in either, though their names/defaults make them predictable.
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 opens with a specific verb and resource: 'Search French companies, associations and public bodies in the official registry (SIRENE/RNE).' It also disambiguates from a key sibling by directing SIREN-based detail lookups to get_company, so the agent can distinguish it from sibling tools without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence provides an explicit alternative and condition: 'Use get_company on a SIREN for directors and financials.' This tells the agent when to switch from this summary-search tool to a more detailed tool, which satisfies the when-to-use/alternative guidance.
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

kyb-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![kyb-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/iGitScor/kyb-mcp/badges/card.svg)](https://glama.ai/mcp/servers/iGitScor/kyb-mcp)

Score Badge

Copy to your README.md:

[![kyb-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/iGitScor/kyb-mcp/badges/score.svg)](https://glama.ai/mcp/servers/iGitScor/kyb-mcp)

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/iGitScor/kyb-mcp'

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