ph-compliance-mcp

Cross-references for a statute

show_cross_references

Read-onlyIdempotent

Retrieves curated cross-domain references and statute-to-statute citation edges for a Philippine statute, enabling discovery of related legal provisions across compliance domains.

Instructions

Curated cross-domain references (from the domain registry) for the statute's domain, plus statute→statute citation edges from the corpus graph.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Max graph edges (default 50, max 100)
`statute`	Yes	Statute short title, e.g. 'Civil Code of the Philippines'
`actNumber`	No	Optional act number override, e.g. '386'

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	Yes
`domain`	Yes
`status`	Yes
`statute`	Yes
`crossReferences`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.12.0Sep 15, 2026

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already communicate read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds some context by identifying the data sources ('domain registry' and 'corpus graph') and the curated nature of the references, but it does not explain limit behavior, possible empty results, or how the two edge types interact.

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 dense sentence with no filler. It front-loads the core output components and avoids redundant restatement of the title or annotations.

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 that the tool has a rich output schema and annotations covering safety, the description is largely complete for a read-only cross-reference lookup. The main gap is the lack of differentiation from sibling tools, but that is more of a usage-guidance concern than a completeness concern for the tool's core behavior.

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 has 100% description coverage for all three parameters, including examples and constraints. The description does not add parameter-level detail, but the baseline of 3 applies because the schema already carries the semantic weight.

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 what the tool returns: curated cross-domain references from the domain registry plus statute-to-statute citation edges from the corpus graph. It uses a specific resource and adds provenance, going beyond a mere restatement of the tool name/title. It does not explicitly contrast with siblings, but the composition of the output is reasonably clear.

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 guidance about when to prefer this tool over siblings like show_citations, related_laws, or show_dependencies. There are no explicit use cases, exclusions, or alternative routing hints, so an agent must infer when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.